这篇文章出自我司 CAIO 野哥之手。（CAIO 不是骂人的，而是 Chief AI Officer，也是我们公司目前非常重要的一个战略岗位。）
前段时间的一次复盘会上，野哥提出了一个相当激进的愿景：公司里的所有事情，最终都应该尽可能实现 AI takeover。这里说的不是简单地让 AI 帮忙写几段文字、生成几行代码，而是让 AI 真正接管从思考、设计到执行和迭代的完整过程。
这个想法自然引发了不少同事的讨论。
那天晚上，我和野哥一起去吃饭。路上我对他说，你应该算是对 AI 最理想化、也最激进的那一派。
但后来想了想，我发现一个很有意思的现象：在我接触过的人里，往往越是能力强、越长期深入使用 AI、越了解它真实进展的人，对 AI 未来的判断反而越乐观，甚至越激进。
比如 Anthropic 的 Dario Amodei。他认为，AI 可能在未来几年大幅加速生物医学研究，甚至让人类寿命显著延长直到超过“死亡”的逃逸速度。我认识的另一位吴教授则判断得更加直接：在 Fable-5 之后再迭代一两个版本，也就是一两年之后，AI 可能会取代绝大多数脑力劳动。
这些预测未必会完全按照他们给出的时间表发生。但至少有一点很有意思：真正站在技术前沿、每天近距离观察 AI 能力增长的人，往往不是更保守，而是更敢于想象它最终会走到哪里。野哥显然也是其中之一。
下面这篇文章，就是他对 AI takeover 软件工程这件事的一次系统思考：当 AI 已经能够独立完成一个又一个开发任务之后，我们是否还应该把架构判断重新交给人类？还是应该进一步建立一套由 AI 自主维护、执行和演进的架构控制系统，让 AI 从“自动写代码”真正走向“自主软件工程”？
当需求已经交付、测试全部通过，为什么下一次修改反而更难？
AI 编程正在从“辅助人写代码”走向“由 AI 自主完成整个开发循环”。需求进入队列，AI 编码智能体（Agent）读取代码库、实现功能、运行测试、修复失败、提交变更；故障、监控和 用户反馈又回到队列，触发下一次循环。
围绕编码智能体不断叠加计划、实现、测试、评审、修复和反馈回路的实践，通常被称为 循环工程（Loop Engineering）。
过去半年，我们团队在多个真实项目中持续实践 AI 驱动的 SDD（Specification-Driven Development，规格驱动开发）。相关流程逐步沉淀在公开仓库 castbox/guru-trellis 中。最直观的变化是：局部任务 完成得越来越轻松，人不再需要持续盯住每一步实现。
但另一个现象也越来越明显：一次任务成功、十次任务成功，不等于这些成功能够自然组合成 一个长期健康的系统。状态开始出现多个权威，规则在不同位置重复，文档和代码逐渐分离， 修复一个缺陷又唤醒另一条隐含链路。
每个局部 Agent 都交付成功，不代表整个软件系统仍然健康。
最容易想到的补救办法，是重新增加人工评审，让资深工程师替 AI 守住架构。但如果每一轮 技术决策最终仍要由人类裁决，AI 自主开发的上限就永远受制于人的时间、经验和吞吐量。
本文追问的是一个更激进、也更重要的问题：
人类只需要提供产品意图、AI 无法自行获得的业务事实，以及必要的外部副作用授权；
AI 工程系统可以自主完成高质量设计、高质量交付和高质量持续演进。
InfoQ 的 《为什么黑灯软件工厂会失败》 对这一困境作出了高度相似的描述。其中许多现象，既出现在亲历的项目实践中，也反复出现在 对团队成员的观察和访谈中。但它把系统架构和程序设计的关键判断重新交给人类，与我们希望 走向 AI 自主软件工程的方向存在根本分歧：缺失的不是更多人工技术评审，而是由 AI 自主 建立、执行和演进的架构决策基线。
这种问题诊断上的高度吻合与解决方向上的根本分歧，连同随后对 Afizzy 前端缺陷发散问题的 集中诊断，促成了本文所提出的架构决策基线方法。Afizzy 将成为这套方法论的第一个完整实践 项目：让架构决策基线正式进入每一次 SDD 任务，成为 AI 必须读取、执行、验证、回写和演进 的长期架构权威。
1. 每个 loop 都成功，系统为什么还在变坏
今天的软件工厂已经拥有很多 loop：
需求澄清 loop
计划与实现 loop
测试失败修复 loop
静态检查 loop
安全扫描 loop
代码评审 loop
发布验证 loop
故障恢复 loop
用户反馈 loop
这些 loop 几乎都拥有清晰而快速的局部终态：
测试通过； 构建成功； 页面验收脚本通过； 扫描没有发现问题； 故障指标恢复； 工单状态变为完成。
但是，软件长期质量依赖另一类问题：
相同业务规则是否只有一个权威归属者（owner）； 状态是否有唯一权威和明确作用域； 异步结果是否只在正确身份和生命周期内生效； 新功能是否继续遵循统一依赖方向； 当前修改是否复制了已有能力； 文档、设计、代码和测试是否仍表达同一套事实； 这次变化是否降低或扩大了下一次变化的成本。
这些问题没有几秒钟内就能给出答案的单一判定器。于是，现有 loop 很容易形成一种危险 状态：
每次任务都成功；
每次测试都通过；
代码库却越来越难修改。
因此，真正缺少的不是更多局部 loop，而是一个覆盖所有 loop 的架构演进闭环：
每次任务开始前读取统一架构；
每次任务中遵循统一架构；
每次任务结束后验证并回写统一架构；
新架构继续约束下一次任务。
一个真正有效的架构演进闭环，不能只是再增加一次评审。所有 loop 之上还需要一个能够被 AI 建立、读取、执行、验证和回写的持久架构权威。它既要让已经作出的架构决策持续生效， 又要允许 AI 根据新需求、代码事实和运行证据不断修订这些决策。
2. 问题诊断：局部正确为什么仍会长期发散
要理解这个悖论，关键不是继续增加测试数量，而是看清当前模型究竟会因为什么得到即时 奖励。InfoQ 原文中的几句话，把问题钉在了正确的位置。
2.1 “糟糕的设计不会受到惩罚”
原文写道：
“糟糕的设计不会受到惩罚。”
模型能够很快知道代码是否编译、测试是否通过、工具是否调用成功，却很难在当前任务中 知道一次错误的职责分配会造成什么长期后果。
状态的权威归属错了，可能要到切换账户时才暴露；规则被复制了，可能要到第五次需求调整时 才发生分叉；依赖方向被破坏了，可能要到下一次替换外部系统时才发现无法隔离。
当坏设计没有进入训练和执行过程的奖励、惩罚机制时，模型自然会优先学习：
用最短路径完成当前任务，并通过当前可见验证。
2.2 测试信号和维护性信号并不对称
原文进一步指出：
“验证代码质量的难度比‘测试是否通过’高出几个数量级。”
测试通常在秒或分钟内返回结果；糟糕架构的成本却在周、月甚至年后，通过重复修改、散弹式 变更、回归缺陷和重构困难体现出来。
测试当然重要，但测试主要裁判已经表达出来的预期。它不会自动决定状态应该属于谁、业务 规则应该放在哪里、接口应如何演进，也不会自动发现几个月后的修改成本。
Context Cost 在 《AI 接管编码之后，程序员还剩下什么？》 中也从可验证反馈的角度解释了这种不对称：编译、测试和性能指标为编码提供了紧密的反馈 闭环，而架构与产品决策的后果往往要经过更长周期才能显现。这有助于解释为什么 AI 可以 迅速掌握局部编码，却不会自然获得维护代码库长期质量的能力。
2.3 当前基准测试很难评估糟糕设计
原文还有一句关键判断：
“糟糕的设计正是当今基准测试无法评估的一环。”
多数编程基准给出一个相对完整的问题，在固定代码快照上评估一次补丁。真实软件工程却是 连续变化：第一轮需求不完整，第二轮改变假设，第三轮要求复用，第四轮引入迁移，第五轮 还要在保留兼容性的前提下重构。
维护性不是一个补丁的静态属性，而是代码库面对连续变化时表现出来的动态属性。
2.4 模型评审能提高下限，却不是维护性预言机
原文也提醒：
“依靠模型来评判代码质量，终究存在局限。”
让一个模型生成代码，再让另一个模型根据模糊的“代码质量”做主观判断，可以发现许多 问题，但没有建立真正的长期质量标准。生成模型和评审模型还可能共享相似的训练盲区。
需要改变的不是评审模型数量，而是评审对象：
从“你觉得这段代码好不好”
变成
“它是否遵循已接受的架构决策、详细合同和变更边界，并留下了什么可验证证据”。
这正是架构决策基线的意义。
3. Afizzy：这不是理论上的担忧
Afizzy 是一个经历过完整版本开发并持续演进的真实前端项目。它在后续迭代中出现的缺陷 发散、状态归属、异步链路和需求—设计—实现漂移，为这套方法论提供了直接的实践基础。
3.1 项目不是从“完全没有设计”开始的
Afizzy v1.0.0 曾按照需求、设计、实现的阶段顺序完成。也就是说，它并不是一个一开始就 完全依靠氛围编程（Vibe Coding）生成的项目。
问题出现在后续持续迭代中：
AI 声称实现已经完成，仓库内测试也通过，但需求明显没有完整实现，已完成部分仍被 质量验收（QA）多次打回； 修复一个缺陷后出现新的缺陷，甚至已经修复的问题重新出现； 线上崩溃（Crash）和应用无响应（ANR）一度处于较高水平，经过持续治理才逐步受控。
这说明一次完整的前期设计并不能自动保证后续几十次 AI 迭代仍然遵循它。
3.2 调查快照呈现了典型的“局部完成、整体发散”
调查当时从 TAPD 项目管理系统的迭代与缺陷快照中看到：
一个遗留缺陷汇总条目包含 51 个未关闭（非 Closed）缺陷； 问题高度集中在账户串数据、角色缓存、Persona（角色）/Chat（对话）作用域、生成任务 状态、购买权益等场景； 仓库已有 232 个普通测试，但只有 4 个 integration_test；部分现行规范仍记录旧 GuruSDK 版本，甚至声称仓库没有 test/，与代码事实明显脱节；状态权威归属、状态作用域、异步结果生效条件、多存储投影和重复实现缺乏稳定的长期权威。
这并不意味着所有缺陷都由同一个架构错误造成，但它们呈现出相同的结构性特征：
一次修复只控制了一个可见症状；
拥有同一语义的其他写入路径、缓存、异步回调和状态副本仍然存在；
下一次变化再次激活这些隐含分歧。
局部补丁消灭了一个缺陷，系统中重复的状态权威和隐式状态却继续制造新缺陷。
3.3 真正的问题不是“AI 不认真”，而是没有长期架构权威
调查逐渐把问题从“提示词不够好”“测试还不够多”“AI 实现不可靠”推进到更根本的层次：
v1.0.0 的设计没有成为每次后续任务的强制输入； 新需求可以重新决定状态权威归属、依赖方向和外部边界； 设计和代码变化没有稳定回写到同一个长期架构来源； 测试主要证明局部代码行为，没有证明完整产品路径和架构一致性； 文档、设计、代码、测试和线上事实之间缺少持续校准机制。
换句话说：
项目不是没有设计；
设计只是没有成为后续每一次 AI 迭代都不可绕过的架构权威。
3.4 从修复缺陷转向建立架构决策基线
因此，Afizzy 的治理目标不再只是继续处理一个个缺陷，而是先建立：
全项目统一的架构决策和设计细则； 有证据的当前架构事实； 当前实现与目标架构之间的逐模块 GAP（架构差距）； 从当前事实走向目标架构的治理方案； 能与新需求并行推进的渐进式重构计划。
随后形成的 Afizzy 架构决策基线草案按 Foundation（基础约束）、CURRENT（当前事实）、 TARGET（目标架构）、Domain（领域设计）、Integration（集成设计）、GAP（架构差距）、 ADR（Architecture Decision Record，架构决策记录）、Governance（治理规则）和 Plan（演进计划）分区，并逐步吸收状态、异步、持久化、GuruSDK（项目使用的共享软件开发 工具包）、错误、可观测性、测试和演进治理等证据。
从架构决策基线应承担的职责看，这份草案主要记录的是 Afizzy 当前事实、目标架构和项目 固定方案，但其中仍混合了一部分可跨 Flutter/Dart/GuruSDK 项目复用的横向规则。要让基线 真正成为可执行的架构权威，这些内容需要继续明确归属：通用规则进入技术栈横向部分， Afizzy 项目部分只固定它们在账户、Persona、Chat、生成任务、购买权益等具体领域中的实现 方案。
截至 2026 年 8 月 4 日，这份草案仍明确标记为 1.1.0-draft、尚未激活，也没有成为 Guru Trellis 门禁的正式输入或回写目标。这一区别非常重要：
文档已经写出来，不等于架构治理已经生效。
Afizzy 实践的关键，是让项目从“拥有一套架构文档”跃迁到“所有 AI 迭代真正由架构基线 驱动”。
4. “大力出奇迹”：长期强化学习可能是未来
原文把 Claude Code 的优势归因于模型在真实工具执行环境（harness）内进行强化学习， 并概括为：
“Claude Code 之所以获胜，是因为它采用了强化学习。”
这句话表达了作者对行业现象的判断。更重要的是，它指出了一个值得关注的方向：编程模型 的下一次重大突破，可能来自大规模、长周期、真实代码库上的强化学习。
理想训练样本不再只是：
问题 + 单次补丁 + 测试结果
而是：
连续需求变化
+ 多轮架构决策
+ 真实缺陷和回滚
+ 用户选择与运行结果
+ 后续修改成本
+ 代码库长期演进轨迹
模型实验室可能从用户选择、方案采用、缺陷、回滚、变更影响面和长期演进速度中提取信号， 学习哪些设计更容易持续维护。
但点赞数量、更新频率和项目活跃度都只是代理指标：长期不更新可能意味着稳定，高频更新 也可能意味着持续返工。真正有效的长期强化学习必须把这些信号与实际变更成本、缺陷归因、 架构演进和运行结果结合起来。
即使方向成立，普通团队也等不起，也不必等。
普通团队无法修改当前基础模型的训练奖励，却可以先建立一套外置的长期奖励、记忆和控制 系统：
架构决策基线。
这相当于把未来强化学习希望内化进模型的长期工程判断，先变成今天每个项目都能执行的外部 机制。
5. 人类的职责边界：提供产品意图，而不是承担技术评审
InfoQ 原文建议重新前置产品评审、系统架构和程序设计，并让人类继续参与关键判断。它对 阶段的划分很有价值：
产品需求澄清； 系统架构设计； 基于调用关系、类型、方法签名、时序和代码形态的程序设计； 实现。
这与 SDD 所采用的阶段顺序基本一致。分歧不在于要不要设计，而在于谁必须成为最终技术 判断者。
《AI 接管编码之后，程序员还剩下什么？》 对这条边界的划分更接近本文：编码正在被解决，软件设计也正在被解决，真正长期保留在人类 一侧的是问题定义、价值取舍和责任承担。对应到软件工程流程，人类需要提供产品意图、AI 无法自行观察的业务事实，并授权发布、付费、删除数据等现实副作用；这些职责并不等同于 逐项裁决模块边界、状态归属、接口形态和代码实现。
如果每批 AI 代码最终仍需要资深工程师阅读和纠偏，会重新引入三个瓶颈：
AI 能够同时自主处理的任务越多，人类评审积压越严重； 质量上限受可用评审者的时间和能力限制； 架构正确性仍依赖不可规模化的人类隐性知识。
在过渡期保留人工控制可以是一种现实安排，但它不能成为目标架构。如果最终目标是 AI 自主完成高质量软件工程，人类就不能继续充当隐藏的架构决策器和代码质量预言机。
由此可以形成一个明确的工程判断：
当 AI 获得完整产品意图、代码库事实、历史决策、系统设计方法和验证工具，
并被明确授权维护整个项目，而不是只修当前任务时，
它的架构能力足以承担项目的技术决策责任。
在知识覆盖、方案枚举、跨文件分析和持续同步等维度，AI 已经具备相对于单个人类架构师的 结构性优势。这套方法要做的，是让这些优势从一次会话中的偶然表现，变成项目长期稳定调用 的正式能力。
6. 概要设计、详细设计与架构决策基线
把架构职责交给 AI，并不意味着允许 AI 在编码过程中临时决定一切。AI 仍然必须先完成设计， 再把需要跨任务持续生效的决策沉淀为基线。理解这套关系，首先需要区分需求、概要设计、 详细设计和架构决策基线各自解决的问题。
本文中的 架构决策基线 不是某种固定格式的单一文档，而是一套持续生效的架构决策、 状态、版本、证据和治理机制。为了让成熟判断能够跨项目复用、又能在具体项目中精确落地， 其内容通常分为技术栈横向规则和项目固定方案两部分。
6.1 为什么仍然需要设计
不做设计并不等于没有设计，只是让状态放在哪里、规则属于谁、依赖如何连接等决策散落在 编码过程中。AI 越能在较少人工干预下持续实现任务，隐式决策就会积累得越快。
在这套方法中，设计至少承担三项作用：
在低成本阶段确定责任、边界和关键取舍； 让编码不必重新发明系统结构； 为测试和架构验证提供独立于代码的判断来源。
概要设计决定系统的形状，详细设计把这个形状展开为可编码合同。具体方法可参见：
《系统设计方法论和实践取舍》 《AI 时代的软件开发范式：规格先行的可逆小瀑布》
6.2 为什么做了设计仍然需要基线
因为设计解决的是“这个系统或这一轮怎样做”，基线解决的是“所有项目和后续轮次必须 继承什么、允许怎样改变”。
一次设计如果没有状态、版本、适用范围、证据、冲突顺序和回写机制，几轮之后就会退化为 历史快照。不同任务可以各自拥有一份看起来正确的设计，却共同制造冲突。
架构决策基线不是比详细设计更详细的第三层设计，而是：
记录哪些架构决策已经生效；
规定每次任务必须继承哪些决策；
在冲突发生时决定由谁修订、如何验证；
在交付之后接收新事实和新决策的回写；
继续约束下一次概要设计、详细设计和编码。
为了同时处理跨项目的技术共性和项目内的具体落地，这些决策可以分别归入技术栈横向部分 和项目实现部分。但无论如何组织，关键都不是把内容分成几层，而是让已接受的架构决策跨越 单次设计和单次任务，持续拥有约束力。
现有概要设计和详细设计也不会因为“已经存在”就自动成为权威。它们首先是候选输入，AI 需要把它们与产品需求、技术栈横向基线、当前代码事实和运行证据进行校准。被接受的部分 进入或被项目实现基线索引；冲突部分必须形成架构差距（GAP）、架构决策记录（ADR）、 替代方案或有期限的显式例外。
设计描述结构与行为，基线决定哪些设计已经生效、适用到哪里、如何被验证、何时被取代， 以及下一轮 AI 是否有权偏离。
7. 关键答案：让架构决策基线成为长期架构权威
到这里，前面的所有问题开始汇聚到同一个缺口：
模型缺少能够及时惩罚坏设计的长期反馈； 项目缺少跨任务持续生效的架构权威； 一次设计无法自动约束后续几十次迭代； 人工技术评审又无法成为 AI 自主工程的最终控制面。
它们不是四个互不相关的问题，而是同一个缺失对象从四个方向投下的影子：项目没有一份 能够跨任务持续生效、由 AI 自主维护的架构决策基线。
这份基线不是另一套供人参考的文档，而是项目真正运行的架构权威：
编码之前，AI 必须先在基线中建立或继承架构决策；
每次任务，都必须把基线作为正式输入并接受它的约束；
违反基线，必须在当前 loop 中产生失败，而不是留下未来技术债；
交付之后，AI 必须把新事实、新决策和运行反馈回写基线；
更新后的基线，继续约束下一次任务。
架构决策基线不是设计文档的集合，而是 AI 工程系统的长期架构记忆和控制面。
因此，方法论的核心不是“多写设计”，也不是“把架构重新交给人类”，而是把原本散落在 专家经验、历史文档、当前代码和临时会话中的架构判断，变成 AI 能够持续执行和演进的正式 控制面。
一份基线是否成立，不取决于写了多少文档，而取决于它是否同时具备四个性质：
权威性：每次任务都必须读取，冲突时不能被临时方案静默覆盖； 可执行性：决策能够映射到设计、代码、测试、依赖图和运行证据； 可演进性：新事实和新决策能够以版本、证据和取代关系回写； 持续性：更新后的结果自动成为下一次任务的正式输入。
这四个性质把架构从“某次设计活动的输出”变成“所有开发 loop 共同依赖的控制面”。坏设计 不再只产生遥远的维护成本，而会因为违反当前有效决策、缺少证据或没有完成回写，在本轮 任务中立即失败。
7.1 AI 必须拥有完整架构职责
AI 不只是根据已有架构写代码，还要承担：
建立、维护和选择技术栈横向基线； 从产品意图归纳架构驱动； 审计当前代码并恢复 CURRENT； 建立 TARGET 和关键 ADR； 把 CURRENT 与 TARGET 比较为原子 GAP； 为新需求生成概要和详细设计； 判断新需求应继承、修订还是取代旧决策； 检查实现是否符合架构； 根据代码变化和运行证据同步项目实现基线； 把经过反复验证的项目经验提炼为横向基线候选； 规划并执行后续渐进式演进。
如果 AI 只被授权写代码，而不能修订架构，它就无法维护长期正确性；如果 AI 可以随意修订 架构，却不留下证据、版本和取代关系，基线又会失去权威。
完整职责必须与完整治理同时存在。
7.2 新项目和存量项目都能建立基线
新项目先选择或建立适用的技术栈横向基线，再从产品意图建立初始 TARGET、领域权威归属、 外部合同、关键 ADR 和第一批详细设计。
已经高度发散的存量项目也不晚，但顺序必须是：
选择或恢复适用的技术栈横向基线
-> 固定代码和依赖快照
-> AI 恢复有证据的 CURRENT
-> 分离事实、推测和目标
-> 根据产品意图建立 TARGET
-> 比较形成 GAP
-> 制定渐进式 PLAN
-> 后续普通迭代开始受基线约束
不能把期望目标写成当前事实，不能因发现 GAP 就自动授权全库重构，也不能等待全部存量 修复后才禁止新增同类问题。
8. 架构决策基线应该包含什么
让基线成为长期架构权威，才是方法论的核心。在本文的方法中，为了让成熟技术判断能够跨 项目复用，又能在具体项目中精确落地，基线内部按两类内容组织：
技术栈横向部分：保存同类技术栈可以跨项目复用的原则、约束和实现规则；
项目实现部分：保存这些规则在当前产品、领域、交互和代码中的固定落地方案。
这只是基线的内容组织，不是另一套独立方法论。具体目录可以随组织和项目规模变化，读者也 不需要照抄下面的名称。判断内容是否完整，可以追问两个问题：同一技术栈下，AI 是否拥有 完整、统一、可执行的工程规则；进入具体项目后，AI 是否知道这些规则在每个领域、交互和 代码位置上究竟怎样落地。
8.1 技术栈横向部分：覆盖完整工程链路的约束集
技术栈横向部分与某个具体产品无关，面向一类相同或相近的技术栈，定义所有项目都应继承 的设计原则和约束。它必须足够具体，使不同 Agent 在不同项目中面对同类问题时不会重新 发明方案，至少覆盖：
架构与依赖：技术栈版本、分层模型、依赖方向、模块边界、共享能力归属、扩展点； 代码组织：目录、包、文件、类型、接口、函数、变量的职责、可见性、粒度和命名； 状态与异步：状态权威归属、作用域、生命周期、并发、取消、幂等、去重、过期结果； 数据与一致性：模型、存储、缓存、索引、事务、迁移、同步、兼容和数据所有权； 错误与韧性：错误分类、传播、映射、重试、超时、熔断、回退、补偿和降级； 配置与集成：配置来源、密钥、SDK（软件开发工具包）、API（应用程序接口）、消息 边界、协议适配、版本和失败语义； 安全与隔离：身份、权限、租户、隐私、敏感数据、审计和外部副作用授权； 运行质量：日志、指标、追踪、性能、资源、容量、可用性和故障恢复； 测试与验证：单元、合同、集成、端到端、静态分析、架构适应度和运行证据； 交付与演进：生成、构建、依赖升级、发布、迁移、回滚、弃用和兼容策略； 治理元规则：规则优先级、适用范围、版本、例外、证据、废止和升级流程。
其中“细化到函数命名”不是追求形式主义，而是为了消除隐藏分歧。例如，读取缓存、触发 远程加载、改变状态和执行外部副作用的函数应通过命名和类型合同被清晰区分；否则 Agent 很容易在调用端误判一个函数是查询还是命令、是同步读取还是启动异步过程。
每条重要规则最好都具有可执行结构：
规则 ID + 适用范围 + 设计理由 + 正例/反例
+ 可确定性检查 + 必要语义审核 + 例外条件 + 版本与取代关系
只有这样，横向基线才能从“供人参考的最佳实践”变成 AI 每次设计和编码必须消费的输入。
例如，一套 Flutter/Dart/GuruSDK 横向规则不需要知道 Afizzy 的“Persona”是什么，但必须 规定状态权威归属如何唯一化、异步结果如何绑定身份与生命周期、SDK 边界如何封装、错误 如何归一、界面组件（Widget）与应用状态如何分工、测试应该覆盖哪些合同，以及类型和函数 怎样命名。
这不是普通编码规范。编码规范通常只关心代码长什么样；技术栈横向规则同时决定系统为什么 这样分层、每类责任属于哪里、实现必须满足什么运行合同，以及如何自动验证。
如果这些规则必须由极少数资深架构师事先写好，人工瓶颈就只是被前移了。因此，建立横向 规则本身必须是 AI 自主完成的工程任务：锁定技术栈及其版本，读取官方规范、最新文档、 变更记录和源码，系统枚举工程决策面，生成带有适用范围、理由、反例和验证方式的规则， 再通过独立上下文审核、确定性门禁和真实项目试运行后激活版本。
“事无巨细”不等于预知未来，而是要求已声明版本和范围内的已知决策面全部受控。任务一旦 触及未覆盖区域，就必须返回 baseline_incomplete，先由 AI 补全和验证基线，不能直接 编码。
8.2 项目实现部分：把通用规则落到固定方案
项目实现部分面向一个具体项目。它继承横向规则，然后把通用原则与项目需求结合，固定为 具体领域、具体场景、具体交互和具体链路中的实现方案。它必须回答：
当前项目有哪些领域、能力、入口和外部参与者； 每个业务规则、状态和数据的唯一权威归属者是谁； 用户交互、调用关系、时序、身份切换和失败恢复如何工作； 通用技术栈规则在当前目录、模块、类型、接口和函数上由谁实现； 当前代码实际是什么，目标架构是什么，中间有哪些 GAP； 哪些概要设计和详细设计已经接受，哪些被取代或仍待校准； 新需求必须继承哪些固定方案，什么变化必须触发新 ADR。
因此，“状态必须只有一个权威归属者”属于横向规则；“Afizzy 当前账户身份由哪个组件持有， Persona/Chat 缓存以什么 key 隔离，切换账户时哪些异步结果必须失效”则属于项目固定方案。 项目实现部分不是把横向规则复制一遍，而是保存“这条规则在本项目中具体落在哪里、由什么 实现、通过什么证据验证”。
项目实现部分还必须表达跨任务持续演进的状态：
CURRENT（当前事实）：系统现在实际上是什么；
TARGET（目标架构）：系统当前决定向哪里演进；
GAP（架构差距）：CURRENT 与 TARGET 有哪些有证据的差距；
DECISION（已接受决策）：为什么这样决定，什么范围内有效；
PLAN（演进计划）：如何在持续交付中逐步收敛。
每次任务都会读取这些状态，也可能改变这些状态。因此，项目实现部分本质上是跨任务持久 存在的状态机，而不仅是知识库。
项目实现基线至少包含以下语义分区：
Foundation（基础约束）：项目边界、质量属性、术语、领域划分和长期不变量； Requirement / Behavior（需求与行为）：产品需求、用例（Use Case）、业务规则、交互和 验收结果； Realization（项目实现映射）：每条横向规则在项目中的权威归属者、模块、类型、时序、 数据和外部边界映射； CURRENT（当前事实）：代码、配置、依赖、数据和运行状态中有证据的当前事实； TARGET（目标架构）：当前有效的项目目标合同和新增代码必须遵循的固定方案； Domain / Integration（领域与集成）：业务行为、状态、规则的唯一权威归属者，以及 SDK、API、消息、存储、 支付、身份和平台能力边界； Accepted Design Index（已接受设计索引）：概要/详细设计的版本、适用范围、被取代 关系和权威入口； GAP（架构差距）：CURRENT 与 TARGET 之间能够独立验证、独立关闭的原子偏移； ADR（架构决策记录）：改变项目架构或申请横向规则特化时的背景、选项、决定、代价 和范围； Governance（治理规则）：变更触发器、例外、技术债、冲突顺序、证据和失败关闭规则； Plan（演进计划）：与需求交付并行推进、可回退的渐进式架构演进路线； Evidence（验证证据）：设计、代码、测试、依赖图、运行观测和外部系统验证之间的 追踪关系。
一个 GAP 应说明当前事实、目标决策、证据、影响、共存约束和关闭条件；一个项目固定方案 则必须能映射到真实代码符号和运行链路。只写“采用单一状态源”不够，必须继续回答由谁 持有、谁可写、作用域是什么、如何失效、如何持久化、哪些调用路径必须经过它。
最重要的分区纪律是：
CURRENT 不是 TARGET；
TARGET 不代表已经实现；
GAP 不自动授权修复；
PLAN 不代表机制已经落地；
ADR 草案不等于已接受决策。
Afizzy 项目实现基线草案能够不断发现并修正文档自身的冲突，正是因为这些语义拥有明确 归属，而不是把当前实现、理想架构和迁移计划混写在同一份“最终设计”里。要让这份基线 真正生效，还需要把其中可跨项目复用的 Flutter/Dart/GuruSDK 规则抽离为技术栈横向部分， 并让 Afizzy 通过版本引用继承，再把整个基线接入任务门禁和交付回写。
8.3 架构决策基线如何与项目及现有设计联合工作
技术栈横向部分提供跨项目规则，项目实现部分把规则实例化为固定方案；现有设计只是候选 输入，真实交付证据优先回写项目部分，可复用经验经独立验证后才反向演进横向规则。
两类内容之间不是简单的“父文档引用子文档”，而是继承与实例化关系：
项目先锁定适用的技术栈横向规则及版本； AI 根据产品需求，把横向规则实例化为项目权威归属、边界、交互、时序和实现位置； 已有概要设计、详细设计和代码事实经过冲突消解后，进入项目实现部分； 每次 SDD 任务同时受整个架构决策基线约束，不能只符合项目局部设计却破坏技术栈共性； 任务完成后优先回写项目部分；被多个场景反复证明有效、具备跨项目价值的经验，只能先 成为横向规则候选，经独立审核和回归验证后进入新版本。
项目可以裁剪不适用的横向规则，也可以因真实需求提出特化，但不能静默违反。任何冲突都 必须由 AI 形成显式 ADR：说明冲突、理由、作用域、代价、验证证据、失效条件，以及究竟是 项目例外还是横向规则本身需要演进。
用一个简化公式表示，每次任务真正生效的架构上下文是：
有效架构上下文
= 已锁定版本的技术栈横向规则
+ 当前版本的项目实现决策与状态
+ 本次任务经审核的变更合同
9. 把架构基线嵌入每一次开发 Loop
图中中央展示架构决策基线持续参与每一次任务；横向规则和项目固定方案共同构成任务实际 生效的架构上下文。
从这一刻开始，架构决策基线不再是一套等待阅读的文档，而成为每次任务都会改变控制流的 运行机制：任务开始必须读取，编码之前必须继承，交付之前必须验证，结束之后必须回写。
9.1 任务开始：AI 恢复适用架构上下文
AI 首先根据语言、框架、平台和基础设施解析适用的技术栈横向基线及锁定版本，再根据本次 变更涉及的行为、状态、数据、外部系统和质量属性，选择最小但完整的项目 Foundation、 TARGET、Domain、ADR、CURRENT 和 GAP 上下文。
架构决策基线内部的横向规则、项目决策或现有设计发生冲突时必须失败关闭，修订真正拥有 语义的上游来源，不能选择更方便实现的一份文本，也不能让项目通过复制横向规则后悄悄 改变其含义。
9.2 编码前：AI 形成任务级变更合同
变更合同连接长期基线与本次 SDD 工件，至少声明：
本次涉及哪些能力和行为； 命中了哪些技术栈横向规则及其验证要求； 权威归属、状态、持久化和外部边界是否变化； 命中了哪些 ADR 和 GAP； 需要哪些设计增量； 测试、观测、回滚和基线回写目标是什么。
它不是人类审批表，而是 AI 在设计前完成的影响面推理。
9.3 设计和实现：代码只能表达已决定的结构
AI 先确定系统级责任和架构边，再展开关键类型、合同、时序、状态和失败语义。小任务可以 把概要和详细设计压缩在同一份文档中，但不能让实现阶段首次决定关键架构。
如果编码时发现设计不可行，应回到设计或基线修订，再重新驱动实现，而不是让代码变成新 的隐式事实。
9.4 验证：短期行为和长期结构同时接受裁判
验证至少覆盖：
产品行为是否满足； 详细合同是否实现； 项目权威归属、依赖方向和规则单一来源是否保持； 技术栈横向约束是否被完整继承，特化是否拥有显式 ADR； 外部系统与真实运行环境是否提供必要证据。
测试通过但没有架构一致性证据，不能宣称高质量闭环；AI 语义判断没有确定性和外部证据， 同样不能宣称完成。
9.5 收口：AI 必须回写新基线
每次任务结束时，不能在代码和测试完成后直接收口。Context Cost 在 《变更后的设计反思：让每次任务都使代码库更加整洁》 中提出的“变更后设计反思”提供了一个有价值的动作：趁本轮执行路径和证据仍然完整，由 AI 检查：
哪些关联修改、同步对象或设计事实可能被遗漏； 实现是否绕过了既有边界或复制了本应复用的能力； 是否出现没有明确权威归属者的新规则、转换器、策略或状态； 文档、接口规范、测试、模拟实现和代码是否仍表达同一套架构事实； 本轮产生的新事实、新决策和新差距是否已经进入长期治理。
这些问题不是留给人类处理的架构问题清单。AI 必须根据架构决策基线判断：直接修复实现 偏差，补充项目实现映射，建立或取代 ADR，记录新的 GAP，或者在触及未覆盖决策面时返回 baseline_incomplete 并先补全基线。
随后，AI 判断项目实现基线需要回写哪些内容：
CURRENT 是否出现新事实； TARGET 是否被需求合法改变； 是否新增、缩小或关闭 GAP； 是否需要新 ADR 或取代旧 ADR； 是否产生例外或技术债； 演进计划是否需要调整； 设计、代码和测试是否仍然一致。
需要同步而尚未同步时，任务状态应是 sync_required，而不是“代码已完成”。
随后 AI 再判断本轮是否产生可跨项目复用的规律。单个项目中的一次成功不能直接修改技术 栈横向基线；它只能产生候选规则。候选需要说明适用技术栈、已有项目证据、可能破坏的场景、 迁移成本和自动验证方式，经独立审核与回归验证后才可发布为新版本。
10. 让“糟糕的设计不会受罚”变成可执行惩罚
这是整套方法最关键的变化：过去，坏设计的代价要在几个月后的返工和缺陷中支付；现在， 违反架构基线会直接让当前任务失败。
把坏设计的未来代价，前移为当前任务的失败。
项目无法立刻改变基础模型的强化学习，却可以把一部分长期质量转换为当前 loop 能够观察 并立即处理的工程后果。
10.1 使用类型化结果，而不是一句“质量不好”
架构门禁可以返回：
baseline_incomplete：适用技术栈或项目场景仍存在未覆盖、未证实的架构决策面；architecture_conflict：局部方案与已接受决策冲突；contract_incomplete：详细合同不足以无歧义驱动实现；planning_stale：需求或架构变化后，任务计划已经过期；finding：设计、代码或测试偏离权威合同；evidence_required：结论缺少外部或运行证据；sync_required：实现已变化，但基线尚未回写；fitness_regression：新增违规、扩大例外或恶化技术债。
这些结果必须改变控制流：阻止继续实现或完成交付，并返回真正拥有问题的上游层。
这样，糟糕设计第一次在当前任务中拥有了明确代价：
不能继续编码；
不能进入发布；
不能污染下一轮架构基线。
10.2 确定性验证负责可计算部分
适合自动计算的规则应交给 AST（抽象语法树）、schema（结构模式）、依赖图、静态分析、 测试和运行探针，例如：
禁止的跨层依赖； 重复业务规则投影； 未声明的外部访问； 新增循环依赖； 权威归属无法映射到真实符号； 例外过期； 技术债数量或范围恶化； 代码变化后缺少必要基线回写。
10.3 AI 语义审核负责不可完全计算部分
责任归属是否合理、行为是否完整、技术取舍是否满足质量属性，仍然需要 AI 推理。但 AI 不再面对模糊的“请评审代码质量”，而是对照需求、架构基线、详细合同和变更合同进行 有来源的判断。
独立上下文或不同模型可以降低同源偏差，但不能替代确定性验证和真实运行证据。
10.4 使用适应度棘轮阻止存量继续恶化
对于暂时不能一次消除的问题：
允许保持已知存量；
允许专门任务减少存量；
禁止新增同类违规；
禁止扩大既有例外；
一处修复不能兑换另一处新增问题。
这让 Afizzy 这样的存量项目不必等到整体重写后才开始治理，而可以先停止发散，再逐步收敛。
10.5 运行反馈负责打破 AI 自证循环
需求、设计、测试、代码和评审都可能由 AI 生成，不能只靠这些工件彼此一致证明产品正确。 还必须使用独立现实信号：
用户是否完成目标行为； 业务结果是否正确； 第三方系统是否接受真实请求； 崩溃、应用无响应（ANR）、错误、延迟和资源指标是否正常； 发布、迁移和回滚是否真实可执行； 后续变更的影响面和返工量是否下降。
这些信号反向修订需求认知、质量属性、CURRENT、GAP 和 ADR，形成项目级长期奖励。
11. SDD、架构决策基线与 Guru Trellis 的分工
三个控制面解决不同范围和时间尺度的问题：
11.1 SDD 是单次任务闭环
需求 -> 概要/详细设计 -> 任务 -> 实现/测试 -> 验证
它保证当前任务先形成规格和设计，再编码，并允许偏差回到正确上游。
11.2 架构决策基线是跨任务、跨项目的架构控制面
技术栈横向基线 vN
├─> Afizzy 项目基线 v1 -> 任务 A -> 项目基线 v2 -> 任务 B -> 项目基线 v3
└─> 其他同栈项目基线 v1 -> 任务 X -> 项目基线 v2
多个项目反复证明有效的候选规则 -> 横向基线 vN+1
架构决策基线跨越了单次任务的生命周期。它的横向部分让不同项目、不同 Agent 和不同模型 继承同一套技术栈判断；项目部分让同一项目的不同任务和会话持续继承固定的领域与实现方案。 两类内容共同服务于同一个目标：让架构决策持续生效、接受验证并随真实交付演进。
11.3 Guru Trellis 是让流程与基线都不可跳过的执行骨架
castbox/guru-trellis 中的 Guru Team preset（团队流程预设）已经提供了 AI 优先（AI-first）的流程骨架：独立新上下文 （fresh context）、需求澄清、规划门禁、实现、Phase 2（语义一致性检查阶段）、独立分支 审核、发布审核和最终收口。
它强调：
AI 直接读取实时权威、代码差异（diff）和证据； 只持久化直接消费者无法可靠恢复的最小数据； 语义判断与确定性记录分离； 使用类型化结果把失败路由回正确阶段； 长期文档不能被单次任务的临时材料替代。
从当前流程能力看，仍存在一个决定性缺口：
架构决策基线
尚未成为这些门禁的正式输入和正式回写目标。
要补上这一缺口，无需另建一套流程，只需把架构决策基线接入现有 Guru Trellis，并在读取 和回写时正确区分横向规则与项目实现：
任务开始时解析并锁定适用的技术栈横向基线版本； 再解析项目实现基线中与本轮行为、领域、状态和集成相关的最小完整上下文； 规划门禁检查本轮概要/详细设计是否继承了适用的架构决策，或通过 ADR 合法修订； Phase 2（语义一致性检查阶段）和独立审核检查代码、测试与架构决策基线的一致性； 收口门禁检查项目 CURRENT、TARGET、GAP、ADR、PLAN 和设计索引是否需要同步； 同步后的项目基线成为下一次任务输入，可复用经验进入横向基线候选队列； 横向候选经独立验证发布新版本后，由各项目显式升级，不能被静默漂移。
完成接入后，SDD 才能从“每个任务先设计”升级为“整个项目持续遵循并演进统一架构”。
12. 从 Afizzy 开始：把方法接入真实项目
落地不需要暂停业务开发，也不需要先把整个代码库推倒重写。Afizzy 采用的是一条可以与 正常需求交付并行推进的路径：
建立并激活架构决策基线
-> 校准需求、设计和代码事实
-> 让基线成为任务正式输入
-> 让基线成为交付正式回写目标
-> 在普通需求和缺陷迭代中持续演进
这不是 Afizzy 才能使用的特殊方案。任何新项目或存量项目，都可以按同样顺序从下一个真实 任务开始建立闭环。
Afizzy 已经具备完整实施这套方法的现实基础：
经历过完整版本开发，而不是玩具项目； 后续迭代出现过测试与需求完成脱节； 存在缺陷发散、状态和异步问题、崩溃与应用无响应等现实压力； 已形成有证据的 CURRENT、TARGET、GAP 和渐进式计划草案； 草案中同时出现了项目特定决策和可跨 Flutter/Dart/GuruSDK 项目复用的规则，适合落实 两类内容的归属、继承与回写； Guru Trellis 已经拥有可扩展的 AI 优先治理骨架； 架构基线尚未接入流程，但接入位置、输入输出和演进方向已经清晰。
核心人员在这一过程中负责明确目标、统一实施节奏、推动架构决策基线与 Guru Trellis 接入， 并确保方法持续执行；他们不需要成为每次任务的人工架构裁判。领导作用从“亲自给出所有 技术答案”转变为“建立并推动 AI 能够持续给出高质量答案的工程系统”。
12.1 阶段 A：建立并激活架构决策基线
当前 1.1.0-draft 仍是 Afizzy 的候选项目实现基线。AI 需要：
建立或选定适用的 Flutter/Dart/GuruSDK 技术栈横向基线； 把草案中可跨项目复用的架构、状态、异步、SDK、测试和命名规则提炼到第一层； 在 Afizzy 项目层保留账户、Persona、Chat、生成任务、购买权益等具体领域方案； 为每个项目方案记录其继承的横向规则、落地符号和验证证据； 完成独立架构审核、状态和版本校准，再通过明确动作激活当前架构决策基线。
激活前不得拿草案阻断开发，激活后也不能随意绕过。
这个阶段本身就是方法落地的一部分，而不是由人类架构师预先准备好全部技术答案。横向规则、 项目固定方案、冲突处理和激活结论都由 AI 产生；核心人员负责推动范围收敛、流程接入和 持续执行。
12.2 阶段 B：完成需求、设计和当前代码事实校准
项目实现基线不能替代产品需求和发布事实。Afizzy 还需要完成 v1.1.0 需求、现有概要/ 详细设计与当前代码的权威一致性校准，明确：
什么是已确认需求； 什么是当前实现事实； 什么是实现缺陷； 什么是架构偏移； 什么是未来目标。
现有设计在校准过程中只是候选证据，而不是天然权威。它与需求、横向基线或运行事实冲突时， AI 必须明确选择纳入、修订、取代、记录 GAP 或建立项目例外。各类权威分开后，AI 才不会 通过修改文档把错误代码合法化，也不会用未来架构改写历史发布事实。
12.3 阶段 C：让基线成为 Guru Trellis 正式输入
每次 Afizzy 需求和缺陷任务必须先解析命中的 Flutter/Dart/GuruSDK 横向规则，再解析项目 实现上下文，并在设计中声明：
锁定了哪个横向基线版本，命中哪些规则； 继承哪些决策； 修订哪些决策； 命中哪些 GAP； 是否引入新状态、持久化、外部边界或异步身份； 需要回写哪些架构对象。
12.4 阶段 D：让基线成为正式回写目标
没有回写，基线会再次陈旧。任务不能在只完成代码和测试时结束，必须同步项目的新事实、 新决策、GAP 状态、例外、设计索引和计划。
如果本轮发现了可跨项目复用的 Flutter/Dart/GuruSDK 规律，AI 只能提交横向基线候选，不能 直接让一次 Afizzy 局部结论改变所有项目。候选通过独立审核、反例搜索和回归验证后，才能 发布新的横向版本，再由 Afizzy 和其他项目显式选择升级。
12.5 阶段 E：进入长周期 AI 自主迭代
完成接入后，真实功能、缺陷、重构、迁移和依赖升级都按照架构决策基线与 SDD 闭环展开。AI 自主完成架构、详细设计、代码和测试，人类只提供产品意图、业务事实和外部副作用授权。
每次交付都继续积累项目基线、横向规则和运行反馈，使这套方法随着真实迭代不断成熟。
一旦第一轮闭环完成，下一次任务就不再从模型的临时记忆和代码猜测出发，而是从已经验证、 已经回写、仍在演进的架构权威出发。此后每一次产品交付，也同时成为一次架构积累。
13. 不要等待下一代模型，从下一个任务开始
Loop Engineering 当前遇到的问题，并不能证明 AI 无法完成高质量软件工程。它真正证明的 是：我们把一个又一个局部任务交给了 AI，却没有同时把整个系统的架构责任、长期记忆和 演进权威交给它。
如果解决方案是让人类重新阅读所有代码、裁决所有技术设计，那么 AI 自主开发最终只是把 编码环节自动化，整个工程系统仍然停在人的吞吐量上。
另一条路已经清晰：真正需要重新打开的，不是人工评审的灯，而是 AI 软件工厂中的 架构控制回路：
让 AI 自主建立和维护架构决策基线；
让每次 SDD 任务强制读取并遵循基线；
让 AI 先完成架构决策，再展开设计、实现和验证；
让坏设计在当前 loop 中产生类型化失败；
让代码事实、运行反馈和新决策持续回写基线；
让更新后的基线继续约束下一轮开发；
在基线内部，分别管理可复用的横向规则和项目固定方案。
未来，长周期真实代码库上的强化学习可能把这些能力进一步内化到基础模型中。但团队今天 就可以把缺失的奖励、记忆和控制结构建立在项目内部。
第一步不需要庞大改造，也不需要等待一套覆盖所有未来场景的完美基线：
选择一个真实项目和明确的技术栈范围；
让 AI 恢复当前事实并建立最小可用的架构决策基线；
让下一个真实任务正式读取并遵循它；
没有完成验证和基线回写，就不允许任务宣称完成。
第一轮闭环一旦转动，后续每次需求、缺陷、重构和升级都会同时产生两类结果：产品继续交付， 架构继续积累。AI 不再只是完成眼前的任务，而是在持续维护一个越来越明确、越来越统一、 越来越能够自主演进的软件系统。
最终的软件工厂不应是：
AI 不断产出代码，人类不断替它做技术裁决。
而应是：
产品意图驱动，AI 自主决策，架构决策基线约束，SDD 展开，证据自动验证，运行反馈持续
回写的自我演进软件系统。
Afizzy 将是这套方法的第一个完整实践项目。它已经具备项目基线草案和 Guru Trellis 流程 骨架；把架构决策基线接入正式门禁与回写闭环后，每一次需求、缺陷和重构都会同时推进产品 交付与架构积累。
这条路线不要求团队等待下一代模型，也不要求每个项目先拥有一位二十年经验的架构专家。 核心人员负责带领实施、统一节奏并确保流程持续运行，AI 负责建立、执行和演进技术架构。 团队已经拥有清晰的方法、现实的落点和能够持续积累的工程路径。
这不是给 AI 增加一套文档流程，而是把它从自动编码推向自主软件工程。
从下一个真实任务开始，软件工程闭环不再只关闭需求和缺陷，也开始关闭架构。
参考资料
Dex Horthy，《为什么黑灯软件工厂会失败》，InfoQ 中文译文，2026。 Dex Horthy，Why Software Factories Fail，英文原文。 Lianghui Zhang，What's Left for Programmers After AI Takes Over the Code?， 讨论可验证反馈、软件设计自动化与人类职责边界。 Lianghui Zhang，Post-Change Design Reflection: Making Every Task Leave the Codebase Cleaner， 提出在每次变更结束后检查边界绕过、能力归属、重复实现和文档同步的实践。