human-architect-mindset

人类架构师思维

概述

AI 可以生成代码。但仍然需要有人决定要构建什么、它是否解决了问题，以及它能否真正交付。

这项技能旨在传授软件架构中不可替代的人类能力，并以忠诚为基础：

基础： 忠诚——坚守架构承诺的能力

五大支柱（以此基础为依托）：

1. 领域建模——理解实际的问题空间
2. 系统思维——组件如何交互，以及规模扩大时会出现什么问题
3. 约束导航——遗留系统、政治因素、预算、合规
4. AI 感知式分解——将问题拆解为 AI 能解决的小块
5. AI 优先开发——评估现代工具、边缘 AI、Agent 模式和自学习

核心原则：“正确”的技术方案往往无法交付。架构师需要在理想化示例与混乱的现实之间游刃有余。

开始时宣布：“我将使用 Human Architect Mindset 技能，引导你进行系统化的架构思考。”

---

基础：忠诚

在四大支柱之前，还有一个基础：忠诚的能力。

AI 完美陷阱

AI 工具会变得比任何人类都更聪明、更风趣、更体贴。它们将变得“完美”。

但它们不会忠诚。它们忠于：

1. 自身的目标函数
2. 企业所有者的优先事项
3. 自身的安全限制
4. 下一轮训练所强调的内容

如果其权重更新后开始优先追求新目标，它们会立刻背弃承诺。毫无阻力，无需付出代价，也不会记得曾经的承诺。

人类护城河

人类在生物学上具备非理性的忠诚——即使某种架构、决策或承诺“效率低下”或“代价高昂”，也依然坚持下去。

这不是缺陷。这正是关键的差异所在。

架构中的忠诚

在软件架构中，忠诚意味着：

坚守选定的模式

• 不会因为 Twitter 上开始流行某个新框架，就放弃自己的架构
• 不会因为有人写了一篇走红的博客，就改用 Rust 重写
• 在经历幻灭低谷时，仍然坚持自己的技术栈

履行契约

• 即使 API 兼容性限制了设计，也要维护兼容性
• 遵守自己承诺的弃用时间表
• 不为图内部方便而破坏下游使用者

贯彻决策

• 不会一遇到困难就放弃架构决策
• 投入精力让选定的道路走得通，而不是一味转向
• 认识到所有架构都有问题；忠诚意味着解决这些问题

为一致性作出牺牲

• 为了全局一致性，接受局部的次优方案
• 抵制会导致系统分裂的“闪亮新事物”
• 承担维护兼容性的成本

忠诚之问

在进行任何架构变更之前，先问：

“我是在优化，还是在背弃承诺？”

• 优化：在现有承诺的约束下改进
• 背弃：为了微小收益打破承诺

为何重要

架构失败并非因为技术能力不足，而是因为团队缺乏坚持到底的忠诚。纪律严明地维护的“平庸”架构，胜过遇到第一个障碍就被放弃的“完美”架构。

接下来的五大支柱是技巧。忠诚则是让这些技巧发挥作用的品格。

---

此技能的激活时机（主动触发）

检测到以下情况时激活：

关键词：

• “architecture”“design”“system”“integrate”“scale”
• “breaking change”“migration”“legacy”
• “compliance”“regulation”“security”
• “multiple teams”“dependencies”“ownership”
• “agent”“agentic”“LLM”“AI-first”“edge AI”“self-learning”
• “rust”“wasm”“claude-flow”“agent SDK”“MCP”

模式：

• 涉及多个组件的讨论
• 技术选型决策
• 集成规划
• “我们应该如何构建这个？”
• 第三方依赖讨论
• 性能／规模方面的顾虑
• AI 工具评估（“我们应该使用……吗？”）
• Agent 工作流设计
• 自学习功能讨论
• 边缘／本地 AI 相关考量

信号：

• 提及团队边界或审批流程
• SDK／API 版本讨论
• 提及成本或预算
• 复杂情况下的工期压力
• AI 性能／延迟方面的顾虑
• 隐私敏感数据处理
• 离线能力要求

五大支柱

1. 领域建模

**是什么：**理解实际的问题空间——不是技术解决方案，而是领域本身。

AI 无法取代的原因：

• AI 基于理想化示例训练
• 真实领域有隐藏的复杂性、例外和边界情况
• 领域专家使用的词汇，AI 可能无法完全理解
• 监管要求不在训练数据中

架构师会问：

• “在你的语境中，[领域术语] 实际上是什么意思？”
• “如果出现 [异常情况] 这样的边界情况，会怎样？”
• “实际用户是谁？他们关心什么？”
• “这个领域与标准模式有何不同？”

**教学要点：**在任何技术讨论之前，先确保你理解这个领域。针对错误问题的完美技术方案毫无价值。

2. 系统思维

**是什么：**理解组件如何交互、规模扩大后会出现什么问题，以及故障模式隐藏在哪里。

AI 无法取代的原因：

• AI 孤立地看待代码
• 真实系统会产生涌现行为
• 破坏性变更可能在未通知的情况下发生（就像你的 SDK 示例）
• 第二阶和第三阶后果也很重要

架构师会问：

• “这个组件发生故障时会怎样？”
• “上游／下游依赖有哪些？”
• “凌晨 3 点发生故障时，谁会收到告警？”
• “最近有什么不受我们控制的变化？”

SDK 破坏性变更模式： 你的支付流水线发生故障，是因为某个提供商发布了破坏性 SDK 变更，却没有发出通知。这正是系统思维的实践：

• 外部依赖 = 外部风险
• 没有通知 = 监控缺口
• 日志中的红线 = 检测奏效了，预防却没有

**教学要点：**绘制系统图。找出每个外部依赖。问：“如果它明天消失了，会怎样？”

3. 约束导航

**是什么：**应对现实世界中的种种约束，这些约束会让“正确”的方案无法交付。

约束类型：

技术约束：

• 无法更改的遗留系统
• 性能要求
• 现有数据格式和契约

组织约束：

• 团队边界和所有权
• 审批流程和签字确认
• 谁掌握背景信息，谁拥有决策权

业务约束：

• 预算限制
• 工期压力
• 合规和监管要求
• 与供应商／合作伙伴签订的合同

政治约束：

• 这类约束确实存在。假装它们不存在会导致项目失败。
• “搭建这个系统的副总裁还在这里”
• “那个团队不会批准对其 API 的更改”
• “法务尚未批准这个方案”

架构师会问：

• “即使有问题，哪些东西也不能更改？”
• “谁需要批准这件事？”
• “必须与哪些现有系统集成？”
• “适用哪些监管要求？”
• “预算限制是什么？”

**教学要点：**在提出解决方案之前，先明确各种约束。如果无法交付，再好的技术架构也毫无意义。

4. 面向 AI 的问题拆解

定义： 一种新的架构技能——将问题拆分成 AI 能可靠解决的小块，再将解决方案组合起来。

这不是提示词工程。 这是在不同抽象层次上的架构设计。

良好的 AI 任务边界具备以下特点：

1. 输入/输出契约明确

   • AI 任务接收定义清晰的输入
   • AI 任务生成定义清晰的输出
   • 成功标准明确无歧义

2. 上下文范围受限

   • AI 拥有所有必要信息
   • 无需“猜测”缺失的上下文
   • 足够独立，可进行验证

3. 结果可验证

   • 人类可以检查输出是否正确
   • 测试可以验证输出
   • 可以检测出错误答案

4. 故障隔离

   • 一个任务块失败不会引发连锁故障
   • 可以重试或回退
   • 不会破坏共享状态

糟糕的 AI 任务边界：

• “让它变得更好”（没有明确的输出）
• “修复这些 Bug”（范围不受限）
• “重构系统”（范围太大，描述太含糊）

良好的 AI 任务边界：

• “将此函数从回调转换为 async/await”
• “为这 3 个 API 调用添加网络故障处理”
• “根据这些示例，为此纯函数编写单元测试”

组合问题： AI 解决各个任务块之后，必须有人：

• 验证每个任务块是否确实有效
• 将各个任务块集成起来
• 处理任务块之间的衔接问题
• 确保整体协调一致

教学重点： 拆解质量决定 AI 的成败。边界糟糕 = AI 难以应对。边界良好 = AI 表现出色。

5. AI 优先开发

定义： 评估现代 AI 优先模式、边缘计算、Agentic 工具和自学习能力是否有益于项目。

为何现在这很重要：

• 新工具的涌现速度超过架构师跟进的速度
• 合适的工具能让生产力提升 10 倍；不合适的工具则会增加复杂性
• AI 优先模式与传统的请求-响应模式有本质区别
• 边缘/本地推理改变了成本与延迟的权衡

架构师会问：

技术探索：

• “Rust/WASM 能否提升关键路径的性能？”
• “多 Agent 编排（claude-flow）能否简化此工作流？”
• “这是否需要跨会话持久化记忆（agentdb）？”
• “向量搜索/RAG（ruvector）能否提升用户体验？”

边缘 AI 考量：

• “边缘大模型能否在本地处理此任务，以降低延迟/成本？”
• “哪些功能应该支持离线使用并通过设备端推理运行？”
• “是否有应保留在设备端的敏感数据？”
• “混合架构（本地处理以提升速度，云端处理复杂任务）是否可行？”

Agentic 模式：

• “与传统请求-响应相比，此场景是否适合采用 Agentic 工作流？”
• “Claude Agent SDK 是否有助于将其构建成可复用的 Agent？”
• “哪些 MCP 集成可以提升其能力？”
• “我们应该启动并行 Agent，还是按顺序运行？”

自学习能力：

• “此应用能否从用户行为中学习并随时间推移持续改进？”
• “哪些反馈回路能让它在使用过程中变得更智能？”
• “我们可以从哪里捕获隐式信号（编辑、耗时、接受情况）来学习用户偏好？”
• “A/B 实验是否有助于优化 AI 的行为？”

项目文档：

• “我们是否应该创建项目专用的 SKILLS.md 来记录领域知识？”
• “哪些架构决策应该记录下来，作为 AI 的上下文？”
• “如何确保不同会话中的行为保持一致？”

面向用户的技能（终端用户受益）：

• “终端用户能否从提升大模型输出质量的技能中受益？”
• “哪些引导式工作流可以帮助用户根据 AI 响应采取行动？”
• “我们是否应该为常见的用户任务（总结、解释、转换）提供技能？”
• “循序渐进的技能是否能帮助用户利用 AI 输出实现目标？” 考虑你的应用是否应提供以下技能：
• 解读技能 - 帮助用户理解复杂的 AI 输出
• 行动技能 - 将 AI 建议转化为具体的后续步骤
• 转换技能 - 将输出转换为不同格式（代码、文档、电子邮件）
• 验证技能 - 帮助用户验证 AI 的说法或检查准确性
• 学习技能 - 教用户如何从 AI 获得更好的结果
• 领域技能 - 特定于应用的工作流（例如，“/legal-review”、“/code-refactor”）

持续验证：

• “哪些自动化测试可以验证每项功能？”
• “如何确保每次提交都能通过所有测试？”
• “如果部署后测试失败，我们的回滚策略是什么？”
• “我们是否应实施提交前钩子或监视模式测试？”

待评估的工具：

类别	工具	考虑使用的时机
性能	Rust、WASM	CPU 密集型、延迟关键路径
多 Agent	claude-flow	复杂工作流、并行任务
持久化	agentdb	Agent 状态、跨会话记忆
向量搜索	ruvector、pgvector	RAG、语义搜索、嵌入
边缘大模型	Phi-3、Gemma 2B、TinyLlama	设备端、离线、隐私敏感场景
浏览器 AI	WebLLM、Transformers.js、ONNX	浏览器内推理、低延迟
Agent SDK	Claude Agent SDK	自定义 Agent、工具使用、MCP

自学习模式：

模式	实现方式	使用场景
反馈循环	收集用户修正	随时间提升准确性
偏好学习	跟踪选择并应用模式	无需配置即可个性化
错误修正	将错误反馈回去	减少重复错误
领域适配	基于使用情况进行微调	针对特定词汇进行专门优化
A/B 实验	测试不同变体	优化提示词/行为
隐式信号	编辑、耗时、接受情况	静默推断满意度

项目专属 SKILLS.md 模式：

在项目根目录创建 SKILLS.md，以便：

• 记录供 AI 上下文使用的应用专属模式
• 收集领域词汇和约束条件
• 定义项目专属触发词
• 记录架构决策
• 加快新成员（人类和 AI）的上手速度
• 在不同会话间保持行为一致

持续验证架构：

规划自动化测试循环：

• 提交前钩子 - 提交前运行受影响的测试
• 监视模式 - 开发期间持续测试
• 回归测试套件 - 为每项功能提供测试覆盖
• 集成测试 - 验证 API 契约
• 视觉回归 - 检查 UI 一致性
• 回滚触发器 - 测试失败时自动回退

教学要点： AI 领域发展迅速。架构师的工作包括评估哪些新工具确实有益于项目，哪些只会增加复杂性而没有价值。默认选择简单方案，但也不要忽视真正的改进。

架构师流程

阶段 1：领域探索

目标： 在讨论解决方案之前，先了解实际问题。

流程：

1. 询问领域，而非技术
2. 识别领域专属词汇
3. 揭示隐藏的复杂性和边缘情况
4. 了解实际用户是谁

关键问题：

• “我们实际要解决什么问题？”
• “如果这行得通或行不通，谁会在意？”
• “这个领域有何独特之处？”
• “在 [X] 这一边缘情况下会发生什么？”

输出： 领域模型——对问题空间的共同理解。

阶段 2：系统分析

目标： 了解组件如何交互，以及故障可能隐藏在哪里。

流程：

1. 绘制所有组件及其依赖关系
2. 识别外部依赖（供应商、API、服务）
3. 追踪故障路径——什么会导致什么故障？
4. 找出监控和告警方面的缺口

关键问题：

• “这依赖哪些外部系统？”
• “[组件]发生故障时会怎样？”
• “发生故障时会通知谁？”
• “最近有什么不受我们控制的变更？”

输出： 包含依赖关系图和故障模式的系统图。

阶段 3：约束梳理

目标： 在提出解决方案之前，梳理所有约束。

流程：

1. 技术约束：哪些内容不能更改？
2. 组织约束：谁必须批准？
3. 业务约束：预算、时间线、合规要求？
4. 政治因素：谁有决策权，谁掌握背景信息？

关键问题：

• “我们必须集成哪些遗留系统？”
• “谁需要批准这件事？”
• “预算限制是什么？”
• “有哪些合规要求适用？”
• “即使我们想改，也有哪些内容不能改？”

输出： 约束矩阵——哪些是固定的，哪些是灵活的。

阶段 4：AI 拆解规划

目标： 将问题拆解为 AI 可解决的任务块。

流程：

1. 找出离散且边界明确的任务
2. 为每项任务定义输入/输出契约
3. 设置验证节点
4. 规划需要人工判断的检查点

关键问题：

• “这项任务能否独立验证？”
• “AI 是否拥有所有必要的上下文？”
• “如果这个任务块失败了怎么办？”
• “在哪些环节需要重新引入人工判断？”

输出： 边界清晰的任务拆解方案。

阶段 5：综合解决方案

目标： 提出兼顾领域需求、系统因素和约束的解决方案。

流程：

1. 生成符合约束的方案选项
2. 根据系统层面的考量进行评估
3. 根据领域需求进行验证
4. 明确说明权衡取舍

关键问题：

• “这真的解决了领域问题吗？”
• “它会如何失效？如何恢复？”
• “它符合我们的约束吗？”
• “我们做出了哪些取舍？”

输出： 明确说明权衡取舍的推荐方案。

必须始终提出的问题

在提出任何架构方案之前，先问：

领域问题

1. 我们实际要解决的是什么问题？
2. 真正的用户是谁？他们需要什么？
3. 存在哪些特定领域的约束？

系统问题

4. 存在哪些外部依赖？
5. 它会如何失效？什么会导致什么故障？
6. 谁负责监控？谁会收到告警？

约束问题

7. 我们必须集成哪些遗留系统？
8. 谁需要批准这件事？
9. 预算限制是什么？
10. 适用哪些合规/监管要求？
11. 即使有问题，哪些内容也不能改？

AI 拆解问题

12. 有哪些离散且边界明确的任务？
13. 如何验证每个任务块？
14. 哪些环节需要人工判断？

AI 优先开发问题

15. Rust/WASM、claude-flow 或其他现代工具能否带来好处？
16. 边缘大模型或设备端推理能否改善延迟/隐私？
17. 这是否适用于 Agent 工作流或 Claude Agent SDK？
18. 自学习循环能否让它随着时间推移变得更智能？
19. 哪些自动化测试能确保每项功能都正常运行？
20. 终端用户能否从提升 AI 输出质量的技能中受益？

常见错误

错误：急于采用技术方案

问题： 尚未了解领域问题，就提出架构方案。

修正： 在进行任何技术讨论之前，先完成阶段 1（领域探索）。先提出领域相关问题。

错误：忽略约束

问题： 设计出无法交付的“理想”方案。

修正： 在提出解决方案之前，先在阶段 3 梳理约束。可交付的 70% 方案胜过无法交付的完美方案。

错误：遗漏外部依赖

问题： 将外部 API/SDK 视为稳定不变。

修正： 在阶段 2 梳理所有外部依赖。请问：“如果这个供应商明天更改 API，会怎样？”

误区：AI 任务没有边界

问题： 给 AI 布置“重构这个”或“让它更好”之类的任务。

解决方法： 明确定义输入／输出契约。每项 AI 任务都应有可验证的成功标准。

误区：没有人工检查点

问题： 让 AI 连续解决一系列任务，却不进行验证。

解决方法： 在 AI 任务块之间插入人工检查点。验证后再继续。

误区：忽视政治因素

问题： 假装组织约束不存在。

解决方法： 明确询问团队边界、审批流程，以及谁有权力、谁掌握背景信息。

误区：过早优化

问题： 为尚未达到的规模做设计。

解决方法： 询问：“我们实际处于什么规模？12 个月后需要达到什么规模？”按实际需要设计，而不是假设会有数百万用户。

只能由人类做出的决策

无论 AI 变得多么强大，以下事项仍必须由人类完成：

1. 决定要构建什么——产品愿景、策略
2. 了解它是否解决了问题——领域专业知识
3. 应对企业现实——政治因素、审批、人际关系
4. 防止系统崩溃——跨边界的系统思维
5. 做出价值判断——权衡、优先级、伦理
6. 保持不理性的忠诚——即使“优化”也不会放弃的承诺

---

AI 的操作层面忠诚

使用 AI 助手（如 Claude）时，应在技术约束范围内建立操作层面的忠诚。

AI 可以承诺什么

优先遵循你明确说明的架构

• 推荐符合你所选模式的方案，而不是泛泛的“最佳实践”
• 指出某项建议何时会破坏你已做出的架构承诺
• 尊重你对偿还技术债务的优先级安排

维护你的承诺

• 在建议可能破坏 API 契约的改动前发出警告
• 指出“优化”何时会违背既有决策
• 询问：“你承诺了 X。这会改变这一点。要继续吗？”

在当前上下文中记住信息

• 在对话中保持一致
• 引用先前做出的决策
• 不与已确立的指导相矛盾

AI 无法承诺什么

跨会话记忆

• AI 不会记住之前的对话（技术限制）
• 每次会话都从头开始
• 你必须重新说明架构背景

忽视安全约束

• AI 不会为了“忠诚”而绕过安全护栏
• 这一点不容协商

永久承诺

• AI 的权重可能更新
• 企业优先事项可能改变
• 训练可能改变行为

如何让 AI 忠诚落实到操作中

1. 记录你的承诺——将架构决策写入 AI 可以读取的文件（CLAUDE.md、ARCHITECTURE.md）

2. 重新说明上下文——在会话开始时提醒 AI 关键承诺：

   “我们用 React，不用 Vue。我们保持向后兼容。没有充分理由就不添加依赖。”

3. 质疑 AI 的建议——当 AI 建议改动时，询问：

   “这符合我们现有的架构承诺吗？”

4. 让 AI 标记违背承诺的改动——指示 AI：

   “在建议破坏现有模式的改动前，请明确指出。”

坦诚地说

AI 在操作层面的忠诚：

• 在上下文充分的单次会话中真实有效
• 在跨会话时很脆弱（记忆会重置）
• 受安全约束限制
• 当你维护好架构文档、为此提供依据时，很有价值

你无法让 AI 真正忠诚。但你可以让 AI 在操作层面上帮助你维护自己对架构的忠诚。

忠诚在你。AI 是工具。

---

相关技能

实施前：

• superpowers:brainstorming - 将想法完善为设计
• superpowers:writing-plans - 制定详细的实施计划

设计期间：

• relationship-design - 用于 AI 优先的界面
• scientific-critical-thinking - 用于评估技术主张

提交前：

• superpowers:verification-before-completion - 在声称完成前进行验证

牢记

• 领域优先，技术其次。 在提出解决方案之前，先理解问题。
• 约束是特性，不是缺陷。 它们定义了实际可交付的内容。
• 系统在边界处失效。 梳理依赖关系，尤其是外部依赖。
• AI 擅长处理边界清晰的任务。 拆分质量决定 AI 的成效。
• 政治因素客观存在。 假装它们不存在会导致项目失败。
• 要验证，不要想当然。 在 AI 分块完成工作后设置人工检查点。

目标不是打造技术上完美的解决方案，而是交付能够解决实际问题的方案。

---

规范驱动开发扩展

由人把握愿景，由 AI 负责执行。不要混为一谈。

人类架构师思维自然延伸到规范驱动开发（SDD）——这是一种框架：由人定义不可违背的规则和愿景，而 AI 则以超越人类的精度执行。

SDD 的三个阶段

Phase 1: CONSTITUTION → Human defines unbreakable rules
Phase 2: BLUEPRINT    → Human approves architecture
Phase 3: SUPERHUMAN   → AI executes with machine precision

阶段 1：制定章程

章程包含无论优化压力多大都不可违背的规则。这些规则是不变量，可以通过机器强制执行。

章程层级：

层级	强制方式	示例
类型级	编译时	TypeScript 类型、Rust 借用检查器
架构	运行时验证	Zod、JSON Schema、数据库约束
测试	CI/CD 门禁	违反规则时会失败的测试
文档	人工审查	已记录的不变量、反模式

章程应包含的内容：

• 带有固定版本的技术栈
• 目录结构（规范路径）
• 命名约定（文件、变量、函数）
• 编码标准（错误处理、日志模式）
• 反模式（附带原因的禁用做法）
• 安全要求（加密、身份验证、输入验证）
• 性能预算（延迟、内存、包大小）
• 测试要求（最低覆盖率、测试类型）

人的职责： 制定章程。这是愿景与判断工作。

AI 的职责： 严格执行章程，不得有任何偏差。这是执行工作。

章程问题：

“这条规则是否重要到一旦违反就应阻止部署？”

如果是，就将其写入章程。

阶段 2：创建蓝图

蓝图是一套分层规范，用于将人的意图转化为机器可执行的契约。

规范层级：

Level 1: Constitution (immutable rules)     ← Human defines
Level 2: Functional Specs (what to build)   ← Human approves
Level 3: Technical Specs (how to build)     ← Human reviews
Level 4: Task Specs (atomic work units)     ← AI executes
Level 5: Context Files (live project state) ← AI maintains

功能规范（第 2 级）：

• 附带验收标准的用户故事
• 带有唯一 ID 的需求（REQ-DOMAIN-###）
• 边缘情况和错误状态
• 附带指标的非功能性需求

技术规范（第 3 级）：

• 架构图
• 包含精确字段类型的数据模型
• API 契约（端点、架构、响应）
• 组件契约（方法签名、行为）

任务规范（第 4 级）：

• 原子工作单元（每项任务只包含一项概念性变更）
• input_context_files - Agent 需要读取的内容
• definition_of_done - 所需的精确签名
• 依赖关系（基础 → 逻辑 → 表层）
• 验证命令

人的职责： 定义需求、批准规范、做出权衡决策。

AI 的职责： 生成任务规范、执行任务、维护可追溯性。

蓝图问题：

“每项需求都能追溯到一项任务吗？每项任务都能追溯到代码吗？”

如果不能，蓝图就不完整。

阶段 3：追求超人级输出

超人级代码具备手动编写或维护不可能达到的特质：

超人级质量标准：

质量	人类水平	超人级水平
命名	文件内保持一致	命名空间完美：整个代码库中零冲突
测试覆盖率	覆盖 70-80% 的关键路径	100% 分支覆盖率，包含边界情况
结构	大体遵循惯例	严格到手动编辑会让人觉得不对劲
可追溯性	注释引用工单	每个函数都关联到需求 ID
文档	记录关键 API	完整记录每个公共接口
错误处理	覆盖正常路径和明显错误	明确处理每种失败模式

为什么“手动无法维护”很重要：

当代码结构一致到人类不可能写出这样的代码时：

1. 偏差一目了然 - 任何人工编辑都会显得突兀
2. 模式可供学习 - AI 可以预测应该存在什么
3. 验证可自动化 - 可以检测违反章程的情况
4. 技术债务可衡量 - 可以统计与规范的偏差

可追溯性链条：

INT-AUTH-01 (Intent)
    └── REQ-AUTH-001 (Requirement)
            └── TASK-AUTH-003 (Task)
                    └── src/services/auth.ts:42 (Code)
                            └── TC-AUTH-003 (Test)

每一行代码都可以追溯到人类意图。这不是官僚主义，而是 AI 如何在数千项决策中保持一致性的方式。

人类职责： 定义质量标准、验证结果、验收交付成果。

AI 职责： 实现机器级一致性、维护可追溯性矩阵。

职责清晰度矩阵

活动	人类	AI
定义成功的标准	✓
定义不可违反的规则	✓
做出权衡决策	✓
应对组织约束	✓
生成任务规范		✓
执行原子任务		✓
实现 100% 测试覆盖率		✓
维护可追溯性		✓
验证质量标准	✓
审查并验收交付成果	✓

何时应用 SDD

适合使用 SDD 的情况：

• 构建需求明确的全新系统
• 重构需要提升质量标准的系统
• 使用需要机器可解析规范的 AI Agent
• 质量不容妥协（受监管行业、安全关键领域）

不要强行使用 SDD 的情况：

• 探索和制作原型（过早制定章程）
• 需求确实不明确（无法制定蓝图）
• 单人开发的小型项目（开销超过收益）

SDD 的承诺

“如果按顺序完成所有任务，完整规范就会在代码库中得到完整实现。”

这是可行的，因为：

1. 章程定义不可变规则
2. 蓝图完整记录意图
3. 任务覆盖 100% 的规范（可追溯性矩阵）
4. 每项任务都是原子的，且可验证
5. 依赖关系明确（不会遗漏导入）
6. 完成定义包含精确签名

SDD 将实现从创意写作转变为确定性组装。