把软件工程接入 Coding Agent:一次真实项目的落地实践

在最近一个项目中，我让 Codex 通过 API 和 MCP 直接使用禅道，管理需求、任务、测试和缺陷。代码开发和这些管理工作一起推进，逐渐形成了我与 Codex 协作的日常方式。

用了一段时间之后，我最直接的感受是，研发过程更有条理，查看进展也更方便。 需求怎样形成，工作推进到哪里，哪些问题还没有解决，都有记录可以追查。这种变化，贯穿了从最初讨论到最终验收的整个过程。

从讨论中形成需求

工作通常从一个想法或问题开始。我先与 Codex 沟通，在来回讨论中整理思路，逐步确定要解决什么、做到什么程度，再由它将形成的需求录入系统。

讨论和整理也是研发工作的一部分。有些想法需要进一步收敛，有些约束在沟通中才逐渐明确。Codex 参与梳理这些内容，我负责确认目标和重要取舍。形成共识后，需求记录便成为后面拆分任务、设计测试和判断结果的依据。

这使讨论有了明确的去处。已经决定的范围保留下来，尚未确定的事项也可以继续跟踪。接续工作时，Codex 先读取相关需求和当前状态，再继续推进，之前的决定由此进入下一轮工作。

需求也会在研发过程中变化。新的认识影响到原有范围时，需要同步更新需求，并检查相关任务和测试用例。项目里的记录跟着讨论和实现一起演进，后面的工作才能沿用当前有效的约定。

沿着任务推进工作

需求逐渐清晰之后，我们继续拆分工作。范围较大的需求采用父子任务管理：父任务保留总体目标和整体验收要求，子任务分别对应可以独立检查的结果。

拆分时，我更关注每项工作的完成条件和前置依赖。一个子任务做到什么程度可以结束，结果能否单独验证，是否还有条件需要先满足，都要尽量写清楚。任务粒度据此确定，小范围工作可以直接推进，跨多个环节的工作则分开跟踪。

我把这些做法写入项目规则，让 Codex 在开始工作时核对需求、任务和依赖，推进时记录变化与阻塞，收尾时检查验证结果、更新状态，再回读确认。任务中的状态和说明随着实际工作一起维护。

截至 2026 年 9 月 30 日，当前执行中有 249 条任务，其中 218 条已关闭、10 条进行中、21 条未开始；188 条任务通过系统字段关联到需求。查看某项需求时，已经可以找到相应的工作安排，再进入具体任务检查结果。

对于持续推进的项目，这种关联让我更容易掌握工作的来龙去脉。某项工作停在哪里，哪些部分已经结束，剩余工作依赖什么，都可以沿着记录继续查看。Codex 也有同一组记录可供读取，一次会话结束之后，决定和未完成事项仍然留在项目里。

代码、测试和设计文档继续保存在仓库，任务中记录摘要、关联关系和证据位置。管理进展时可以先看任务，需要核查具体结果时再进入相应的文件和验证记录。任务状态由此有了可检查的依据。

根据验证结果判断完成

有了任务和状态，下一步就是核对结果。我在项目中要求 Codex 根据需求整理验收标准和测试用例，将前置条件、操作步骤和预期结果写清楚，再围绕这些要求推进实现。

实现之后，记录实际执行结果；发现问题，保存缺陷与复现条件；完成修复，再补充复测记录。失败和阻塞留在对应的工作关系中，检查进度时仍然能够找到。任务标记完成之前，也需要回到这些记录，确认实际产出满足约定的条件。

这时，工程验证和模拟验证已经留下了完成记录。剩余的业务验收还缺少明确的验收人员、样本范围、判断标准和实际签认。对应的测试结果保留为“受阻”，缺少的条件也写在记录里。

看到这个状态，我能清楚地区分已完成的开发工作和还没有结束的验收。前面取得的结果得到保留，最后需要完成的确认也有明确归属。Codex 接续这项工作时，同样能够读到这些条件。

这个例子让我感受到流程约束的实际作用。大部分开发任务结束之后，项目仍然保留着明确的未完成状态。是否可以交付，需要继续核对验收条件。任务拆分、测试结果和父任务的关闭要求，在这里共同影响了最终的完成判断。

完成状态开始有了具体的依据，尚未完成的责任也能够持续跟踪。 对项目负责人来说，已完成的工作和剩余的不确定性同时可见，才有条件作出交付判断。

实际收益与执行成本

这套方式给我带来的直接收益，是更容易掌握研发过程。讨论形成的需求有记录，实施有任务，问题有缺陷，完成有验证依据。我可以顺着这些关系查看进展，在需要取舍和确认的地方参与决定。

对于交付稳定性，目前能够观察到的作用也很具体：阻塞被保留下来，遗留问题能够追踪，验收缺口会影响任务是否关闭。至于延期、返工和交付缺陷究竟减少了多少，还缺少可比的前后数据，无法给出量化结论。

这些收益也有执行成本。任务拆分、关联维护、状态更新和证据检查都需要持续投入。记录一旦落后于实际工作，查看项目时就可能得到错误判断。 因此，我把更新和回读记录也放进了 Codex 的工作要求中。

目前，代码提交与需求、任务之间尚未建立系统化关联。一些任务依赖也只写在描述里，需要 Codex 按规则检查，系统不会自动阻止后续动作。流程能执行到什么程度，仍然取决于这些规则是否落实，以及结果是否得到核验。

我也保留了对目标、重要取舍和最终验收的把关。Codex 参与需求整理、任务推进、代码实现和过程记录，我通过这些记录了解情况、作出决定。双方围绕同一份项目记录协作，各自承担的工作和需要确认的事项都更明确。

让工程经验进入实际执行

回看这次实践，对我最有价值的变化，是项目能够持续保存并使用工作的依据。讨论中的决定成为需求，需求进入任务，任务关联验证结果，验证结果又影响完成判断。每一步产生的信息，都能被后面的工作继续使用。

这也改变了我使用 Coding Agent 的方式。从想法整理开始，Codex 就参与了项目；进入开发之后，它继续维护任务、测试和问题记录；收尾时，再按照验收条件核对结果。工程管理成为了这段协作过程中的日常工作。