Ticket #142 写着：“把准备文档的用户名加到 PDF 报告里。”这句话比客户真正想表达的意思少了五个字，而你会用三种方式发现这个差距：现在猜然后做错，现在问然后丢掉节奏，或者先把猜测做出来，下个迭代在客户面前出错。

每个开发者都熟悉这种差距，而且它是双向的。你未必能从一行工单里看出产品或客户到底要什么，产品也未必能看出你到底做了什么，直到东西摆到他们面前——无论是演示、预发链接还是缺陷报告。下游所有环节都会继承这个差距：范围悄悄漂移，“完成”对接触工单的三个人意味着三件不同的事，而修复一次误解的成本，远高于修复一个缺陷。

打开网易新闻 查看精彩图片

这是关于一张工单走完 n2i-dev-cycle 的过程。它是一个 Claude Code 技能，用来缩小这个差距，而不是指望开发者自己记得去补。

9:14 工单落地

执行 /n2i-dev-cycle #142。技能拉取工单，读取项目的 CLAUDE.md，检查记忆里有没有上一个迭代留下的相关内容。然后它问了一个大多数 AI 编码工具会直接跳过的问题：在写任何一行代码之前，这件事到底需要什么？

这个功能涉及三个实体。两个服务需要新增字段，一个前端组件需要新增列。技能没有靠猜然后直接开始敲代码，而是先把它写下来。

9:20 先出计划，不是代码

第三阶段产出一份计划：后端要加哪些字段，需要哪个迁移脚本，哪个前端组件要加新列，哪些单元测试覆盖它。然后它停下来等待。

等待用户批准后再继续。用户可以修改、增加或删除条目。

这个环节通常会被跳过。一句“直接做这个”的提示会直接进入代码，而第一次有人检查计划是否匹配需求，往往是在代码评审，甚至更糟，是在演示时。在这里，计划才是你要评审的产物，而不是代码差异。9:20 发现“其实我们还需要准备人的角色，不只是名字”，只需要一句话；下午 4 点发现，就要重写。

11:40 一次只做一个单元

后端实体开始构建：字段、DTO、服务、控制器、迁移。构建通过。然后它没有继续冲向前面端，而是问：

“后端脚手架完成。继续之前要看一下吗？”

第四阶段每个逻辑单元结束时都会问这个问题。不是建议，是强制检查点。如果悄悄跳过继续做，你就是在用一个还没人确认的后端结构去搭前端。停在这里，一个错误假设只造成一个单元的返工，而不是整个功能。

14:15 测试跑起来

dotnet build、dotnet test、ng build、ng test，循环跑到全绿。这里没有新东西，唯一特别的是它总会发生。在截止时间压力下，测试通常第一个被牺牲，接着是“移动端我晚点再看”和“评审等 MR 提上去再说”。这个技能把这三件事都当作流程中不可协商的步骤，而不是可选项。