我还没从 Thoughtworks 离职的时候（现在在 Qoder 团队），我就想写一篇文章，把一张图里 Loop 那一栏补完整。那张图其实很直白：不是让 AI 生成更多代码，而是让 AI 在工程体系中稳定完成交付。左边是 Rules，把团队经验和开发约束变成 AI 可执行的工作规则；中间是 Spec，把模糊需求收敛成可拆解、可验证、可追踪的交付目标；右边是 Harness，把 AI 行为纳入工程治理边界，确保结果可验证、可度量、可放行。
在 Thoughtworks（现 Inspire） 的最后一个月里，我一直在为“下一个项目”准备一套 AI Coding 的端到端方案。这个方案基于 Claude
在时时使用多个 Codex/Copilot/Claude/Qoder 编写代码之后，我第一次明显感觉到，整个产品推进的节奏都被拉快了。
几个月前，当 Coding Agent 的 CLI
TL;DR：https://github.com/phodal/routa，Harness Monitor 在 crates/harness-monitor 目录下。
今天下午，我在 Routa 的看板里点开一张已经进 Done 的卡：[Sub-issue] 为 GATE-first 专家提示注入单次 trace 状态摘要。
最近这段时间里，我做了一件比“让 AI 帮我写文章”更麻烦的事：不是继续打磨 Prompt，而是先让它系统分析我过去十年的文章，再把这些分析结果整理成一个可以被反复加载的写作
过去大半年里，我一直在帮不同规模的团队落地 AI Coding。从最早的一两个人试点，到十几个人的团队尝试让 AI
在最新的 Routa Desktop 中，我们引入了 Harness 工程可视化系统。它并不是一个展示“AI 写了多少代码”的界面，也不是为了给生成式开发增加一层炫目的仪表盘，
当 AI 开始真正参与软件交付时，团队面对的核心问题已经悄悄变化了。过去我们关心的是代码写得够不够快、自动化够不够多，而现在，越来越多团队首先要回答的是另一个问题：当生成速度不断提高之后，系统靠什么抵抗持续上升的代码熵。