一个一线同学说，已经周四了，他这周的需求还一笔没写。
不是因为需求太难，也不是因为他没有投入。恰恰相反，他一直在投入：按组织要求使用之前的 workflow 工具，反复重试，拆解需求，澄清需求，调整说法。工具效果一直不理想，最后他判断，这周大概率要周末自己加班把需求做掉。
这不是一个"AI 提效"的故事。
这是一个提效工具反过来消耗工程师的故事。
最危险的是工具成功了一半
现在很多组织推广 AIDEV 的方式很激进：上 Harness，上 workflow，设效率目标，推动 Agentic coding，鼓励全栈交付。表面看，这是组织在主动拥抱新范式。
但这里有一个容易被忽略的问题：AI 最先提升的是代码生成速度，不是工程判断速度。
代码更快出来了，PR 更快堆起来了，需求看起来更快进入实现阶段了。可审查速度没有同步提升，架构判断没有同步提升，团队对系统的理解也没有同步提升。于是组织看到的是速度上涨，一线感受到的是验证负担上涨。
Augment Code 在 2026 年的复盘里讲过一个很相似的倒挂：Agent 推广之后，代码产出和 PR 数量上升，但团队的部署信心下降。原因很直接：Agent 生成更多代码，review 成为瓶颈，review 在压力下变成橡皮图章，团队通过了代码，但没有真正理解代码。
这就是 AIDEV 最危险的中间态：工具不是完全没用，而是成功了一半。
它成功地让代码变多、变快、变容易。 但它没有成功地让团队更懂这些代码。
全栈执行免费，判断不免费
AI 之后，服务端同学写前端变容易了，前端同学写后端也变容易了。语法、样板、框架 API、胶水代码，这些过去会拦住人的东西，现在都可以交给 Agent。
所以组织很容易得出一个看似自然的结论：既然 AI 能写，那全栈交付就应该成为默认。
这个推论漏掉了最关键的一层：AI 让跨栈执行变便宜，但没有免费补上跨栈判断力。
服务端同学让 AI 写一个前端页面，通常能判断"页面能不能跑""交互结果对不对"。但他未必能判断组件边界是否合适、状态是否放错层、样式系统是否被破坏、可访问性有没有问题、这个实现会不会让下一个需求变得更难。
前端同学写后端也是一样。接口能通，测试能过，不代表事务边界是对的，不代表错误处理是稳定的，不代表权限模型没有绕开，不代表这个逻辑放在这一层以后还能演进。
过去的执行摩擦虽然烦，但它有一个副作用：它会提醒人"我不懂这个领域"。AI 把这个提醒消掉了。人可以更快越过领域边界，但越界之后是否有判断力，系统并不会自动提示。
所以 AI 时代的全栈能力，不应该被理解成"一个人可以负责所有栈"。更准确的说法是：一个人可以更快在相邻领域执行，但他仍然需要知道哪些东西自己能判断，哪些东西必须找领域 owner 判断。
如果组织把"能生成"误认为"能负责"，代码库会很快开始坏。
过程重新变重要了
我以前对 AI 写代码有一个判断：只要结果正确，过程无所谓。
代码写得是否符合规范，架构是不是优雅，风格是不是一致，好像都不是核心问题。我们要的是最终可执行程序。代码经过编译之后都会变成机器能运行的东西，除了性能、安全和功能正确性之外，所谓架构、风格、规范，似乎更多是人类协作时代留下来的审美偏好。
经历了一段时间从 0 到 1 的 AI 原生开发之后，这个判断变了。
在沙箱里让 AI 写一个小 demo，看起来很厉害。几分钟，一个页面出来了；再几分钟，一个后端接口也出来了。可这些 demo 大部分不可用。不是因为它们完全跑不起来，而是因为它们没有从真实系统里长出来。它们不知道现有 repo 的目录结构、命名习惯、错误处理方式、状态管理边界、历史兼容包袱，也不知道哪些看起来奇怪的代码其实是生产事故之后留下的疤。
要得到生产可用的代码，代码必须从现有 repo 里长出来。
换句话说，仓库就是 Agent 的知识库。现代 Agent 已经非常聪明，它会像一个专业程序员一样扒历史代码：找相似实现，模仿已有 pattern，读文档，读 git message，读测试，甚至读暂存区里那些还没提交但已经暴露出来的改动。它不是凭空写代码，它是在仓库给出的语境里续写代码。
这就改变了"过程是否重要"的答案。
过程重要，不是因为我们突然又迷信代码风格，也不是因为架构洁癖重新赢了。过程重要，是因为过程会沉淀成未来 Agent 的输入。今天为了赶一个需求随手复制的逻辑，明天会变成 Agent 可参考的 pattern。今天为了快一点绕开的边界，后天会被另一个 Agent 当成仓库允许的做法。今天没人清理的一点混沌，会进入下一次生成的上下文。
在这个意义上，代码规范、架构治理、文档合理性，不再只是人类维护成本问题。它们直接决定未来 Agent 的输出质量。
Agent 受限于 LLM 的基本形态：上下文太多之后注意力会下降，局部线索会盖过全局约束，多轮生成会积累偏移。你不可能指望每次需求开发都 100% 符合规范。几乎每次开发都会引入一点混沌量。单次看很小，甚至不值得拦；但如果没有机制把这些坏东西清理掉，仓库的信噪比就会越来越差。
到那时，再想让 Agent 高效稳定地产出代码，就不可能了。因为你给它的知识库已经坏了。
0 到 1 的爽可能被误归因了
最近两个月，我参与了一个公司内部项目。简单说，就是从 0 到 1 重新写一个 app，尽量不复用以前的代码，完全新写。从第一行代码开始，就是 Agent 写的。很彻底的 AI-first。
这个项目本身也带着一个实验问题：网上有一种说法，完全从 0 到 1 的 Agentic coding，效果会好于把一个现有项目改造成 Agentic coding。听起来有道理。旧项目有历史债，有奇怪约束，有没人敢动的模块，有文档和代码不一致的地方。新项目没有这些包袱，Agent 可以按照新的规则直接长出来。
我的感受也确实是：从 0 到 1 开发要爽多了。
但这里有一个很大的归因陷阱。到底有多少爽，是因为它是 AI-native？又有多少爽，只是因为任何 0 到 1 项目本来就爽？
人类自己写 0 到 1 项目也很爽。没有历史债，没有兼容包袱，没有老接口，没有前任留下来的诡异抽象。你可以轻装上阵，目录结构按今天的理解设计，技术栈按今天的偏好选择，所有东西看起来都干净。这个阶段的快乐，很容易被误归因给 AI。我们可能不是在体验"AI-native 开发天然更好"，而是在体验"新项目天然更轻"。
AI 确实进一步放大了这种爽感。过去从 0 到 1 写新项目，爽归爽，但还是要一行行搭骨架。现在 Agent 可以把骨架、页面、接口、测试、配置一起推出来，初始速度非常惊人。问题是，速度也放大了另一件事：代码腐化的速度。
我抽查过这个仓库的一些 MR，已经看到不少不符合架构设计的改动被合并了。它们不是那种一眼就该回滚的错误。恰恰相反，很多改动可能功能上是对的，页面也能跑，测试也过了。但它们和原本想要的架构方向有偏差。单次看没那么严重，合并压力下也容易放过去。
这就是我真正担心的地方：0 到 1 会给人一种窗口期幻觉。刚开始仓库很薄，问题还没有显现；功能增长很快，大家感受到的都是进度；架构偏移还只是几个点，看起来可以以后再收。但如果每个需求都引入一点偏移，三个月之后，这个项目会变成什么样？
让我们拭目以待。
仓库腐化不只发生在代码里
前面一直在说代码，但 repo 里不只有代码。
AGENTS.md、ARCHITECTURE.md、README、设计文档、ADR、代码注释、测试说明、commit message，这些东西不会被编译成可执行程序，但它们都会被 Agent 读到。只要 Agent 会读，它们就是 repo 的一部分。只要它们影响 Agent 的判断，它们就是生产系统的一部分。
这件事比代码腐化更隐蔽。
代码错了，至少还有一些明确的防线。编译会失败，类型会报错，测试会红，线上监控会报警。虽然这些防线不完美，但它们会给你信号：这里可能坏了。
文档坏了，通常什么都不会发生。
ARCHITECTURE.md 过时了，CI 不会红。README 写错了，单元测试不会失败。AGENTS.md 里保留了一条已经不适用的规则，构建系统也不会提醒你。一个注释解释了三个月前的 workaround，但 workaround 已经被重构掉了，这行注释仍然安静地躺在那里。人类可能扫过去，Agent 可能认真读进去。
所以有些人说，AI 写代码比写文档更简单。这句话乍听很反直觉。代码多难啊，要编译，要测试，要跑起来；文档只要写得差不多，语言通顺，好像就可以了。
但从 verify 的角度看，写代码确实更简单。代码至少有相对明确的验证标准。文档没有。文档的错误往往不是语法错误，而是现实错位：它描述的是旧架构、旧流程、旧约束、旧决策。它读起来非常合理，只是已经不是真的了。
AI 时代这件事会变得更危险，因为生产成本大幅下降，verify 成本会成为瓶颈。写一份 ARCHITECTURE.md 很容易，让 Agent 顺手补一段 README 也很容易。真正难的是确认这份文档有没有准确表达当前系统，未来 Agent 读了会不会被误导。
这意味着我们必须像对待生产代码一样，甚至更谨慎地对待文档。
不是所有文档都该多写。相反，AI 时代可能应该少写那些没有验证机制的文档。能放进代码的，就放进代码；能用测试表达的，就用测试表达；能用 lint、边界规则、类型系统、CI gate 表达的，就变成可执行约束。只有那些无法被代码和测试表达、但又会影响判断的东西，才值得进入 AGENTS.md、ARCHITECTURE.md 或注释里。
一旦写进去，就要如临大敌。
因为坏代码通常会在某个时刻暴露自己。坏文档不会。它会继续以"知识"的形式存在，被下一个 Agent 读取，被下一个需求引用，被下一个 MR 复制。代码腐化会让系统难维护；文档腐化会让 Agent 误以为自己理解了系统。
Harness 不该成为 KPI 杠杆
Harness 本身不是问题。真正的问题是组织把 Harness 当成"逼大家提速"的杠杆，而不是当成"降低验证成本"的工程设施。
好的 Harness 应该回答几个问题：
这次 Agent 到底读了哪些上下文？ 它有没有遵守架构边界？ 它有没有复用已有 pattern？ 高风险改动有没有进入更严格的 review？ 生成结果能不能被自动验证、回滚、追踪？ 工程师能不能更快判断它到底做了什么？
如果一个 Harness 没有降低 verification burden，只是让人必须先跑一遍 workflow，那它就是新的流程负担。那个周四还没开始写需求的同学，遇到的可能不是个人使用问题，而是组织把一个尚未成熟的工作流前置成了必经路径。
这类东西在 dashboard 上通常很好看。使用率上升了，workflow 运行次数上升了，AI 参与比例上升了。但一线真实损耗藏在别处：反复重试、重新解释、补上下文、看不懂输出、最后周末自己兜底。
这不是 AIDEV。 这是 productivity theater。
评价标准本身还没准备好
如果组织真的想激进推进 AIDEV，指标也必须换。但说实话，这里比我一开始想的更难。
不要只看 PR 数量、需求吞吐、AI 使用率、代码行数。这些指标在 Agent 场景下太容易膨胀。它们衡量的是产出表面积，不是系统健康度。
更应该关心的维度大概包括这些：
review 深度。审查者是否理解了变更，还是只看 CI 通过就 approve？
返工率和回滚率。Agent 生成的代码有多少在后续被重写、撤回、绕开？
跨领域验收质量。前端写后端、后端写前端时，是否有对应领域的人参与关键判断？
架构漂移指标。重复逻辑、跨层调用、pattern fragmentation 是否在增加？
仓库知识质量。关键文档、注释、ADR、测试和目录结构是否仍然和真实代码一致，还是已经开始误导 Agent？
incident explainability。出问题时，团队能不能解释系统为什么这样表现，还是只能让 Agent 再读一遍代码？
规格覆盖率。关键模块有没有权威 spec、ADR、边界约束，还是 Agent 每次都在猜？
但这些东西说起来像指标，落地时很多并不真正像指标。
有些数据很难收集。返工率怎么定义？一个需求上线后两周被重写，算不算返工？规格覆盖率怎么算？有一份 ARCHITECTURE.md 算覆盖，还是必须覆盖到具体模块、具体边界、具体异常路径？
有些维度又太主观。review 深度怎么统计？跨领域验收质量怎么量化？一个前端 owner 看过后端同学写的前端代码，留下三条意见，是否就说明验收质量高？还是说明问题多？这些数字很容易被收集，但未必真的表达我们想知道的东西。
这不是指标设计上的小瑕疵，而是问题本身的难度。一个事情如果连评价标准都很难做，那它就是很难的。哪怕它符合直觉，哪怕一线工程师都能感觉到"仓库正在变乱"，想要客观评价它仍然很难。
而客观评价是科学优化的基础。没有评价标准，优化就会退化成口号。管理层会继续看最容易统计的东西：使用率、吞吐量、节省人天。工程师会继续感受到那些难以统计的东西：理解负担、review 疲劳、文档误导、架构偏移。
所以也许这件事的第一步，不是立刻发明一个完美 dashboard，而是承认：AIDEV 的仓库健康度评估还处在很早期。我们现在能提出一些方向，但哪些是合理的落地监控指标，哪些只是需要人工判断的健康信号，还没有想清楚。
我现在还没搞明白的一些事
我还没完全想清楚的是，AIDEV 的组织目标到底应该怎么设。完全不设目标，探索可能停留在少数人的个人习惯里；但只设使用率、吞吐量、节省人天，又会把大家推向最容易造假的方向。也许真正该设的是 confidence 类指标，但这些指标比 velocity 难采集得多。
全栈化的边界也还需要更清楚。AI 确实让相邻领域学习变快了，但"能执行"和"能负责"之间有很长一段距离。组织应该鼓励工程师扩展判断力，而不是默认 Agent 已经替他补上判断力。这个边界怎么落到职级、review owner、代码 ownership 上，还没有很成熟的模型。
Harness 团队到底应该像平台团队，还是更像内部 FDE？我倾向于后者。不要先造一个通用工具再要求大家迁移，而是先陪真实业务做几个难需求，在真实交付里证明它确实降低了验证成本。工具自己用着爽，不等于别人用它不会变慢。
还有一个更刺的问题：如果三个月后仓库真的开始难以迭代，组织能不能承认这是 AIDEV 推广方式的问题，而不是一线工程师"不会用 AI"？很多技术债最后都会被解释成执行问题，但它最初常常是指标问题。
我也还没想清楚"清理混沌量"应该做到多强。每个需求之后都做一次架构清理，成本太高；完全不清理，债务会复利增长。也许需要一种类似垃圾回收的机制：日常靠自动规则清理小偏移，周期性由领域 owner 做更深的 pattern 收敛。但这个频率怎么定，暂时还缺少经验数据。
文档验证也还是个硬问题。代码有编译、测试、类型系统，文档靠什么？如果每次文档变更都要求领域 owner 认真 review，成本会很高；如果不 review，它又会变成 Agent 的错误知识源。也许未来需要一种 docs-as-code 的更强版本：文档里的关键断言能被测试、lint 或 repo 查询自动验证。但哪些断言适合自动验证，哪些只能靠人判断，这条边界还很模糊。
还有一个很具体的观察需要继续跟踪：从 0 到 1 的 AI-first 项目，三个月后到底会留下什么样的仓库。如果它仍然清晰、稳定、容易让 Agent 继续生成，那说明 AI-native 起步确实有结构优势。如果它快速变乱，那就说明最初的爽很大一部分只是新项目红利，而不是 AI-native 本身的胜利。
参考文献
- Augment Code (2026). Confidence Is the New Bottleneck. https://augmentcode.com/blog/confidence-is-the-new-bottleneck . 本文使用其关于 Agent 推广后 PR 量增加、review 成为瓶颈、团队理解力与部署信心下降的经验总结。
- Vercel v0 rebuild (2026). Tom Occhino on the pivot from sandbox-first to repo-first generation. 本文使用其关于 sandbox 原型和 repo-first 生产代码之间差异的判断：大多数真实工作是修改已有代码库，而不是从零生成 demo。
- VibeCodiq (2026). Architecture Drift Root Causes. 本文使用其关于多轮 AI session 后定价逻辑、权限逻辑等散落到多处的架构漂移分析。
- Stefan Ve / ArchCodex (2026). I built a 2300-file codebase with AI. 本文使用其关于 executable architecture、AI-assisted development 中 architectural drift 以及约束降低 drift 的经验。
- Matt Pocock (2026). AI-era engineering observations. 本文使用其 "code is the environment the agent operates in" 的判断：代码质量直接影响后续 Agent 输出质量。
- Simon Willison (2024-2026). Coding agent 相关观察与访谈。本文使用其关于 AI 更像放大专家能力、而不是替代专家判断的经验判断。
- Agentic Workflow Migration 调研 (2025). 本文使用其关于标准 productivity 指标在 Agent 场景下失真，以及 comprehension、confidence、review quality 等替代指标的总结。
- BoringDocs (2025). The Hidden Cost of Documentation Drift. 本文使用其关于文档与代码分叉会形成隐性维护成本的判断。