教程列表
按当前目录继续浏览
改表单字段前，让 Codex 从 UI 到数据库追完整数据流
前端工程师改表单字段，最容易低估的不是页面本身，而是字段离开页面之后发生了什么。一个看起来很小的需求，例如“把联系人备注改成客户偏好说明”“新增一个可选的跟进时间”“把收货地址里的楼层字段拆出来”，往往不只是改一个 input、一个 label、一个校验规则。字段可能先被表单库收集，再经过前端 ...
改数据库字段前，先让 Codex 读迁移历史搞清字段为什么长这样
这篇文章教你在改数据库字段之前，用 Codex 把迁移历史读一遍，还原每个字段是什么时候、因为什么加进来的，后来有没有被废弃或加了兼容逻辑。做完后你会得到一份字段演进时间线，以及哪些字段能改、哪些改起来有兼容包袱的判断。它解决的不是“这个字段存什么”，而是“这个字段为什么长成这样、动了会牵连谁”。
给接口加返回字段，先让 Codex 把旧客户端护住
给接口响应加字段，看起来是后端工作里最安全的一类改动。新增字段不影响旧字段，旧客户端不读它，新页面可以直接用它。很多团队会把这类需求当成“顺手加一下”：DTO 里多一个属性，序列化结果里多一段 JSON，OpenAPI 文档补一下，然后发版。
给列表加一个字段前，让 Codex 先找清它从哪来
线上后台里有一种改动特别容易被轻视：列表多展示一个字段。产品说“订单列表加一列发票状态”，你打开页面，看到表格组件，心里觉得也就多一个 column。真正动手后才发现，字段不只在 UI 上出现一次。接口响应里可能已经有 `invoice_status`，前端类型里却没有；API client 可...
工单标签打错，复盘就会把人带偏
客服团队做复盘时，最容易被忽略的一件事是：统计表里的标签不一定是真的。工单系统里显示“产品问题”占比最高，可能只是客服习惯把所有报错都归到产品；“用户不会操作”看起来很多，可能只是帮助中心没有写清楚；“订单异常”连续上涨，可能混进了退款状态说明、支付延迟、库存同步和物流咨询。标签一旦打错，后面的...
工单归因不能只写产品问题，要能指向改进责任
很多客服团队每周都会导出一张工单统计表，里面有咨询量、投诉量、响应时长、解决时长、满意度、关闭率，看起来数据不少。但一到复盘会，大家还是很难讨论下一步怎么改。原因常常不在于没有数据，而在于归因标签太粗。一个工单被标成“产品问题”，产品团队不知道是按钮找不到、规则没写清、接口超时，还是某个模块真的...
公司一句话介绍老变，先填一张品牌口径校准表
这篇文章解决的不是“品牌怎么升级”，也不是“做一整套品牌手册”。它只处理一个更窄但很常见的问题：公司的一句话介绍总在变，官网写一版，路演讲一版，销售开场又说一版，导致客户、投资人、渠道伙伴听到的第一印象不一致。
公众号结尾别再写“欢迎留言”：按读者阶段配好 CTA 台阶
这篇文章教你给公众号文章配结尾 CTA，而不是简单在末尾加一句“欢迎留言”。你会先判断读者读完这篇后处于哪个阶段，再从收藏、留言、下载、加群、咨询五种动作里选一个最自然的下一步，最后产出一个可以复用的 CTA 文案库。做完后，每篇文章都有明确的转化出口，数据上能看出哪一类结尾真正带来了关注、加群...
公众号开头别铺背景：前三段先让读者进现场
公众号文章的开头，最常见的问题不是写得不够正式，而是太想把事情讲完整。编辑一上来先解释行业背景、趋势变化、平台环境、用户习惯和自己为什么写这篇文章。每一句都可能没错，但读者还没看到自己的处境，就已经滑走了。
公众号提纲先想清读者读完要做什么
很多公众号文章不是没有观点，而是观点太早上桌。作者一确定选题，就开始把自己知道的判断、案例、金句、数据和方法全部堆进文档里。写到一半，文章看起来很丰富，却越来越难收束：开头在讲读者痛点，中间变成观点合集，后半段又塞了几个案例，结尾只能写“希望对你有帮助”。
公众号月排期别只填日期：先配平主题比例和素材状态
很多公众号团队的排期表长这样：一行一个发布日期，格子里写“周三推文”，旁边备注“素材跟进中”。到了月底复盘，才发现这个月发了十篇，八篇是行业观点，转化内容只占一篇，互动内容一篇没有；更麻烦的是，有两篇到了发布前一天才临时找素材，最终只能把旧文改改凑数。
供应商说可能要延期，先把影响面拆成一张表再决定怎么谈
供应商发来一句“这批货可能晚一周”，真正难的不是这句话本身，而是这句话落在你负责的链条上会怎样传导：影响哪个项目上线、哪份客户承诺、哪笔预算，以及谁该在什么时候拍板。供应商协作负责人如果直接去催货或直接发延期通知，往往会漏掉中间环节，把本来可以吸收的延期变成客户投诉和内部扯皮。
共享工作区里让 Codex 改代码：先护住别人的改动
多人共用一个分支、一个本地工作区，或者一个远程开发环境时，最危险的不是 Codex 写错一行代码，而是它把不属于自己的改动也“整理”了。你只是让它修一个表单校验，它看到旁边文件有格式不一致，就顺手格式化；你只是让它补一个接口字段，它发现测试失败，就把别人正在改的测试快照更新掉；你让它“恢复到能跑...
构建失败别只看最后一行：让 Codex 找到第一处有效错误
构建失败最容易误导人的地方，是它常常把真正的错误埋在中间，最后只留下一句很大的失败结论。你看到终端底部写着 `ELIFECYCLE Command failed with exit code 1`、`Error: Process completed with exit code 1`、`Buil...
故障确认后，别只说在修：把影响和下次同步时间讲清楚
技术支持客服在产品故障已确认后，最难写的不是“抱歉”，而是怎么把进展讲到足够清楚，又不替研发和产品承诺还没有把握的恢复时间。用户连续追问“到底什么时候好”“影响多大”“你们现在有没有人在处理”，如果客服只回“我们正在紧急修复”，用户会觉得信息不足；如果客服为了稳住用户写“马上恢复”“今天一定解决...
关键词表太长时，先画一张官网教程主题图
官网内容运营拿到一张搜索词导出表时，最容易犯的错是把每个看起来有流量的词都变成一篇文章。关键词越多，题目越多，最后却不一定带来更清晰的内容增长。因为官网教程不是社媒选题，不是哪个词热就写哪个，也不是把标题改得更像搜索框就算完成 SEO。官网教程要解决的是读者带着一个明确任务进入页面后，能不能快速...
官网、销售 PPT 和公众号简介不一致，先做一份对外简介统一包
这篇文章解决的是一个很容易被低估的市场品牌问题：官网、销售 PPT、公众号简介、活动报名页、渠道伙伴介绍里的公司介绍不一致。每个版本单看都能说通，但客户连着看几处以后，会产生一个很朴素的怀疑：这家公司到底做什么？现在主推什么？刚才销售讲的，和官网写的是同一个产品吗？
管理员能看、运营看不到按钮：让 Codex 先画出权限判断链路再动手
运营发来一条消息：“同一个订单详情页，管理员账号能看到‘导出’按钮，我登录后按钮直接消失了，是不是系统出 bug 了？”你打开页面确认：两个账号都能进这个页面，请求也都成功，只是一个有按钮、一个没有。
函数太长先别急着拆：先让 Codex 锁住现有行为
最让人犹豫的重构，往往不是你看不懂代码，而是你看懂之后更不敢动。一个函数三百行，里面混着参数归一、权限判断、金额计算、状态转换、兼容旧数据、日志上报和错误提示。你知道它应该被拆开，也知道继续堆下去会越来越难维护。可问题是：现有测试很薄，历史 bug 又不少，函数里还有几段看起来怪但可能是线上补丁...
合同别直接丢给法务：先用 AI 把背景材料整理成准备单
业务把合同发给法务时，最常见的对话是：“这份合同帮我看看，今天能出意见吗？”法务打开一看，只有一份对方发来的合同扫描件，没有交易背景、没有金额构成、没有谈判过程，连对方公司全称都要自己去查。法务只能先回一长串“请补充以下材料”，来回两三轮，三天就过去了。
会后邮件怎么写，才能把决议和责任发清楚
很多会议不是输在会中讨论，而是输在会后那封邮件。会上大家看起来都点头，散会后却各自带走了不同理解：有人以为只是讨论方向，有人以为已经拍板；有人觉得自己只是配合，有人以为他是负责人；有人听到的是“下周看看”，有人理解成“下周三必须给结果”。等到项目经理再追进度时，问题已经变成“我以为不是我负责”“...
会前 10 分钟：用 AI 把项目会议议程排到能决策
很多项目会议看起来准备好了：会议邀请已经发出，参会人都在日历里，背景材料也丢进了群里。可真正到开会时，主持人才发现最关键的东西还没有被设计清楚：这次会议到底要做出什么决定，哪些信息只需要同步，哪些风险必须展开讨论，哪些行动项要在散会前分配出去。
会议还没结束，就用 AI 把行动项抓准
会议记录人最容易被逐字稿拖住。大家说得很快，方案、任务、限制条件、风险提醒交替出现，你一边追着打字，一边担心漏掉关键句。等会议结束再整理时，文档里确实有很多字，却很难回答三个更重要的问题：刚才到底定了什么，接下来谁要做什么，哪件事有截止时间和前提条件。
会议纪要先写决定，再写讨论过程
一场项目会可能开了 90 分钟，转写稿有两万字，白板上写满了方案、风险、争论和临时补充。可是会后真正需要被组织记住的，往往只有几件事：采用哪个方案、暂缓哪个需求、谁有权确认下一步、哪些问题还没有决定。
会议纪要写完没人动？用 AI 抽成可督办行动单
很多会议纪要并不是没人写，而是写完以后不能直接追动作。纪要里有大量讨论、背景、观点、风险和“大家会后再跟一下”，看起来信息很完整，可到了执行阶段，总助、项目助理或部门负责人还是要重新问一遍：这件事到底谁负责，什么时候给结果，做到什么程度算完成，老板当时拍板的结论是哪一句。
活动报名不少却成交少？把入口、表单、客服和成交节点拆开复盘
活动报名不少，却没有带来相应成交，是活动运营最容易被追问的场景之一。表面上看，报名数已经达标，宣传也没有完全失败；但到复盘会时，老板只问一句：“为什么最后成交这么少？”如果复盘只盯最终成交数，团队很容易陷入互相猜测：渠道说自己带来了足够流量，落地页同事说报名转化不差，客服说名单质量一般，销售说跟...
活动目标太多抓不住重点：先压成三层主线指标
一场活动最容易失控的时候，不一定是预算不够，也不一定是执行慢，而是目标太多。老板希望拉新，销售希望成交，品牌同事希望曝光，社群同事希望活跃，渠道伙伴希望联合传播，最后每个人都能在活动方案里找到自己想要的指标，但执行团队不知道到底该先保什么。
几百行乱表别手工拉：用豆包企业版 AI 表格清洗、汇总、补说明
月底要交回款汇总，你手里却只有一张 400 多行、字段混乱的客户成交明细导出表：客户名一会儿全称一会儿简称，日期有 `2026/7/3`、有 `7月3日`、还有 `2026-07-03`，金额列里混着数字、`未收款` 和空值，状态列有 `已回款`、`回款中`、`待回款`、`丢单` 四种写法，表中...
纪要发出去以后，用 AI 把行动项盯到闭环
会议纪要发出去，不等于责任闭环已经开始。很多项目经理都遇到过同一种尴尬：会议当天大家确认了行动项，纪要里也写了负责人和截止日期；一周后再打开群聊，没人主动更新进度，任务卡在谁那里、是否延期、要不要升级，都要重新问一遍。
季度目标刚定，先拆成每周能验收的动作
季度目标刚定下来时，运营负责人最容易卡在一个地方：目标看起来清楚，执行起来却还是一团雾。老板说这个季度 GMV 要到 480 万，留存要拉到 62%，交付准时率要到 90%，但团队只知道“要增长、要提效、要稳交付”，不知道每周该推进什么、谁负责、到周五怎么判断有没有跑偏。
价格账单 FAQ 要写到用户能自己核对
这篇教程解决的是商业化客服最容易反复消耗时间的一类问题：用户看不懂套餐差异，不确定为什么被扣费，找不到发票入口，不知道续费后权益什么时候生效，客服每次都要翻价格页、订单记录、发票规则和历史回复，最后还可能因为口径不一致引发二次投诉。
简历初筛别靠感觉，把用人经理口径转成可打分标准
很多招聘低效，不是简历不够多，而是 HR 和用人经理对“什么叫符合要求”没有提前对齐。HR 按 JD 初筛，觉得候选人年限够、岗位名接近、行业看起来相关，就推进给用人经理；用人经理一批量退回，理由是“项目不够复杂”“行业不对”“稳定性有风险”“不是我要的那种人”。来回几轮以后，招聘专员觉得业务方...
见客户前，用 AI 准备一份能问出真实需求的追问清单
客户说“想了解一下方案”，并不等于客户已经有清晰需求。很多会面失败，不是因为介绍不够完整，而是你太早进入演示和报价，没有把真实痛点、预算边界、决策链和成交条件问出来。
交付要延期，怎样用 AI 写一封有担当的通知
这篇文章解决一个不舒服但很常见的场景：你原本承诺周五交付一份材料，现在发现关键数据还没有确认，周五发最终版已经不稳。客户或业务方可能还没有来催，但你已经知道原计划要改。此时最重要的不是把邮件写得委婉，而是主动、清楚、负责地说明：为什么延期、影响到什么、你已经做了什么补救、下一次明确交付时间是什么。
接手陌生仓库，第一小时让 Codex 帮你找到路
这篇文章教你在接手一个没有交接文档的陌生仓库时，如何用 Codex 做第一小时的项目导航。你会让 Codex 先只读仓库，识别技术栈、启动入口、关键目录、最近改动和测试方式，再产出一份可以人工核对的“项目入口地图”和“首日检查清单”。
接替岗位 JD 别沿用旧模板，先从交接材料还原真实工作
这篇文章解决一个很具体的招聘问题：员工离职后，HRBP 和用人经理翻出旧 JD，才发现上面写的是“负责部门日常行政支持、供应商对接、数据整理”，但交接材料里真正堆着的是合同续签、费用结算、客户投诉、跨部门催办、系统权限维护、临时活动落地和一堆只有前任知道的判断规则。继续照旧 JD 招人，候选人看...