📒 精彩答疑（一）学霸笔记｜概念篇：建立 AI 原生世界观

Top Student Notes | Q&A (1): Conceptual Foundations — Building an AI-Native Worldview

一、这篇答疑在讲什么？

What Is This Q&A About?

这篇答疑不是在补充某个工具技巧，而是在回答概念篇里最容易“似懂非懂”的问题。
它的价值不在于告诉你一个命令怎么用，而在于帮你把 AI 原生开发背后的几个核心概念分得更清楚、想得更透。

这篇答疑主要围绕 5 类问题展开：

1. 规范、上下文、SDD 等概念怎么区分
2. Spec、Plan、Code 之间的边界和回退逻辑是什么
3. SDD 在真实团队和复杂系统中怎么落地
4. 会话、上下文、成本、污染这些工程问题怎么处理
5. AI 时代开发者，尤其是新手和转行者，应该怎么成长

二、整篇答疑的核心结论

Core Conclusion of This Q&A

一句话总结

AI 原生开发的关键，不只是会不会用 AI，而是能否把“意图、约束、上下文、验证、流程”组织成一个稳定的人机协作系统。

三、规范和上下文怎么区分？

How Do We Distinguish Rules from Context?

这是非常关键的概念题。

Tony 的回答很精炼：

• 规范也是上下文
• 但它属于 约束型上下文
• 普通代码、接口定义、文档等属于 信息型上下文

1. 规范是什么？

规范告诉 AI：

• 必须做什么
• 不能做什么
• 哪些是红线
• 哪些是硬约束

例如：

• 禁止使用 unsafe
• Public 函数必须有注释
• 必须使用 TDD
• 不允许全局变量

所以规范是：

高权重的约束型上下文

2. 普通上下文是什么？

普通上下文告诉 AI：

• 当前系统里有什么
• 代码是怎么组织的
• 数据结构是什么
• API 输入输出长什么样

例如：

• 某个源代码文件
• 某个 JSON 结构
• 某个数据库 schema
• 某个配置文件

所以普通上下文是：

信息型上下文

学霸理解

这个区分非常重要，因为很多人把“都塞给 AI 看”理解成一种统一上下文，其实不够精确。

真正更好的理解是：

上下文 = 让 AI 理解任务的完整语境
其中又分为：
- 约束型上下文：告诉 AI 不能乱来
- 信息型上下文：告诉 AI 有哪些事实可参考

四、团队开发公约属于什么？

What Category Does a Team Development Convention Belong To?

Tony 说得非常明确：

团队开发公约属于高权重的约束型上下文。

因为它不只是背景知识，而是决定 AI 输出是否合规的规则。

学霸理解

这意味着：

• 团队开发公约最好沉淀到 constitution.md
• 它不应该散落在口头默契里
• 它应该成为 AI 工作时长期可见的“法律”

所以这也是为什么课程里一直强调：

• CLAUDE.md 是长期协作上下文
• constitution.md 是规则护栏

五、SDD、spec-kit、Claude 三者的关系

The Relationship Among SDD, spec-kit, and Claude

这是答疑里最适合背诵的一题。

Tony 给出的答案是：

• SDD 是思想 / 方法论
• spec-kit 是实现 / 工具
• Claude Code 是执行引擎

1. SDD 是什么？

SDD = Specification-Driven Development

它是一种开发思想，强调：

• 先写规范
• 规范是唯一事实源
• 再从规范推导方案、任务和代码

所以 SDD 回答的是：

应该如何组织 AI 开发流程

2. spec-kit 是什么？

它是 SDD 的一种工具化实现。

它定义了：

• spec.md
• plan.md
• tasks.md
• 对应的命令和模板流程

所以 spec-kit 回答的是：

如何把 SDD 这套思想工具化落地

3. Claude Code 是什么？

Claude Code 是执行这些工作的 AI Agent 引擎。

它负责：

• 理解 Spec
• 生成 Plan
• 生成 Tasks
• 写代码
• 改代码

所以 Claude 回答的是：

谁来执行这套流程

学霸理解

三者关系可以记成：

SDD = 道
spec-kit = 器
Claude Code = 力

或者：

SDD      → 方法论
spec-kit → 工具实现
Claude   → 执行动力

六、编码时发现架构有问题怎么办？

What If We Discover an Architectural Problem During Implementation?

这是很现实的问题。

因为很多时候架构问题确实不是设计阶段就能完全看清，往往是在实现时暴露出来。

Tony 的回答非常符合 SDD 思路：

回到 plan.md 层修正设计，再更新 tasks.md，然后再继续让 AI 基于新方案实现。

学霸理解

这说明 SDD 不是“前期定死，后面不许动”，而是：

允许回退，但要回退到正确抽象层。

也就是说：

• 需求错了，回 spec.md
• 架构错了，回 plan.md
• 实现错了，改代码

这是 SDD 的一个非常重要的“分层纠错原则”。

七、测试发现 bug，到底该改 spec 还是改代码？

If a Bug Is Found During Testing, Should We Update the Spec or Fix the Code?

Tony 给出的判断标准特别经典：

看这个 bug 是“没想清楚”，还是“没写对”。

1. “没想清楚” → 改 Spec

也就是意图本身有问题，比如：

• 需求漏了边界情况
• 业务规则本身不完整
• 验收标准有漏洞

这种情况说明：

错的是意图源头

那就应该修改 spec.md。

2. “没写对” → 改代码

也就是：

• 规范很清楚
• 但 AI 实现错了
• 有逻辑错误、语法错误、性能问题

这种情况说明：

错的是执行层

那就应该让 AI 修代码，而不是改 Spec。

学霸理解

这一题最值得记住的原则是：

永远维护“意图”的单一来源。

Spec 的职责是保存“本来想做什么”。
如果不是意图变了，就不要乱改 Spec 去迎合错误实现。

八、多人团队里做不到人人都改 spec，怎么办？

What If a Large Team Cannot Ensure Everyone Updates the Spec?

Tony 的回答很务实。

他没有说“必须所有人严格执行，不然不算 SDD”，而是承认现实：

不是所有小修小补都值得强制走 Spec 变更流程。

Tony 给出的落地策略

1. 分级治理

• 大功能、大改动：必须走 Spec 流程
• 小 Bug、小优化：允许直接改代码

2. 用 CI/CD 卡关键流程

没 Spec 的重要变更，不允许合并。

3. 用 Commit Message 做补偿

小改动至少要有清晰记录。

4. 用 AI 做“反向同步”

定期让 AI：

• 读取 git diff
• 更新 spec.md
• 保持代码与规范一致

学霸理解

这说明 SDD 真正落地时，不是“宗教式纯化”，而是：

抓关键变更，接受局部现实，再用 AI 做同步补偿。

九、SDD 能消灭“失落的翻译”吗？

Can SDD Eliminate the “Lost in Translation” Problem?

Tony 的回答非常到位：

不能从物理上消灭信息损耗，但可以把损耗前移。

传统流程的问题

产品想法 → PRD → 研发理解 → 代码实现 → 测试/上线后才发现理解错了

损耗很晚才暴露，返工成本极高。

SDD 的作用

模糊意图 → spec.md 阶段就反复澄清

这样即使损耗还存在，也是在改 Markdown，而不是在重写几千行代码。

学霸理解

Tony 这句非常值得记：

SDD 是“损耗左移”。

也可以理解为：

用前期思考成本，换后期返工成本。

十、spec-kit 很笨重、很线性怎么办？

What If spec-kit Feels Heavy and Too Linear?

这个问题问得很好，Tony 回答也很坦诚：

• 是的，现阶段 spec-kit 偏重型
• 尤其适合全新特性开发
• 不够灵活
• 但这是 spec-kit 的问题，不是 SDD 的问题

Tony 的关键态度

不要被工具绑架。

课程里他自己就没有死用 spec-kit，而是手动跑完整套流程。

学霸理解

这一点特别重要：

规范驱动是一种思想，不等于某个 CLI。

所以最核心的不是：

• 会不会跑某个命令

而是：

• 你能不能自己维护 spec.md
• 你能不能灵活更新 plan.md
• 你能不能按层推进与回退

十一、文档很多、上下文很长，AI 会不会注意力衰减？

If There Are Too Many Documents and Too Much Context, Will AI Lose Focus?

Tony 的回答点出了 SDD 设计上的精髓：

分层。

也就是：

• spec.md 讲业务意图
• plan.md 讲架构设计
• tasks.md 讲执行步骤

所以 AI 不需要每次都吃下全部上下文。

正确做法是什么？

在执行某个任务时，只喂给 AI：

• 当前任务描述
• 相关 spec 片段
• 当前代码文件
• 必要规则

而不是整包全塞。

学霸理解

这说明 SDD 其实也是一种：

控制上下文复杂度的结构化方法。

十二、有状态系统能不能让 AI 自动迭代？

Can We Let AI Freely Evolve Stateful Systems?

Tony 的答案是：

可以，但必须非常谨慎。

因为有状态系统涉及：

• 数据库 schema
• 旧数据兼容
• 数据迁移
• 向后兼容
• migration 脚本

如果只把新需求给 AI，而不告诉它旧数据现实，它很容易生成：

看起来正确、实际上会破坏存量系统的代码。

所以必须补什么？

• 注入 schema / migration 上下文
• 明确兼容性约束
• 明确禁止删除字段等规则
• 人工审查 migration
• 在沙箱环境验证

学霸理解

这里最重要的一句是：

AI 负责生成，人负责为数据安全兜底。

这几乎可以视为有状态系统里的铁律。

十三、会话能不能一直开着？

Should We Keep Using One Long Conversation Session?

Tony 的回答很明确：

理论上可以，工程上强烈不推荐。

原因有三个：

1. 自动摘要是有损压缩

会话很长时，早期细节会被模糊甚至丢失。

2. 上下文污染

上一个任务的错误尝试、临时思路，会污染下一个任务。

3. 成本和延迟上升

上下文越长，token 越多，费用和响应时间越高。

学霸理解

最值得记住的建议是：

一个任务，一个会话。

公共记忆放进 CLAUDE.md，而不是靠单个超长对话维持。

十四、为什么会话费钱得这么快？

Why Does a Conversation Become Expensive So Quickly?

Tony 解释得很清楚：

一个会话从启动到退出之间，所有历史都会持续带着走。
所以历史越长，每次请求要带的 token 越多，费用就越高。

正确做法

• 不要一个会话做完整项目
• 一个功能点完成后就 /clear 或重启
• 把共通知识沉淀到 CLAUDE.md

学霸理解

这里背后的工程原则是：

长期记忆要文档化，不要会话化。

十五、开发者往前一步后，和产品的边界在哪里？

If Developers Step Forward, Where Is the Boundary with Product Managers?

Tony 的回答很有启发性。

产品经理负责：

• 定义模糊业务价值
• 关心用户体验和业务目标

AI 原生工程师负责：

• 把这种模糊价值“编译”成无歧义的 Spec

所以边界不再只是“需求文档”，而是：

可执行规范

学霸理解

这意味着：

• 开发者不一定要变成产品经理
• 但必须更懂业务
• 因为只有懂业务，才能把需求写成 AI 可执行的规范

所以未来更有价值的是：

懂产品的开发者

十六、如果我没有判断对错的能力，怎么监督 AI？

What If I Don’t Yet Have the Ability to Judge Whether AI Output Is Correct?

这是非常现实的问题，特别适合新手。

Tony 的回答非常重要：

不会判断代码时，先学会判断测试。

为什么测试这么关键？

因为你不一定能直接看懂复杂实现，
但你至少应该学会判断：

• 测试场景是否覆盖业务
• 输入输出是否合理
• 边界是否考虑到了
• 失败条件是否定义清楚了

所以 Tony 才说：

TDD 是小白的救命稻草。

学霸理解

AI 时代，一个新人的成长重点会发生变化：

过去：

• 学怎么写代码

现在：

• 先学怎么定义“什么是对的”

只要你能写清楚正确标准，AI 就更容易替你完成实现。

十七、为什么说最危险的是被 AI“喂废”？

Why Is the Biggest Risk Becoming “Mentally Spoon-Fed” by AI?

Tony 的提醒非常深刻：

如果你把思考的痛苦完全外包给 AI，就会失去最宝贵的快速成长期。

这句话很值得所有新手反复看。

学霸理解

AI 最大的风险不是替代你，而是让你误以为自己已经掌握了。
真正危险的不是“不会写”，而是：

• 不再主动分析
• 不再主动验证
• 不再主动拆问题
• 不再主动补基础

所以 AI 时代最重要的自我要求之一是：

让 AI 替你搬砖，但不要替你停止思考。

十八、对半路出家的开发者有什么建议？

What Advice Does Tony Give to Career Switchers?

Tony 的回答非常平衡，不鸡血，也不唱衰。

第一阶段：先借 AI 快速做出东西

AI 对转行者是巨大福音，因为它可以帮助你：

• 快速做产品
• 快速建立信心
• 快速获得正反馈

这是非常重要的。

第二阶段：基础会成为你的天花板

AI 能帮你从 0 到 1 做出来，
但结构、性能、安全、架构质量还是需要你判断。

所以基础知识也许不再是“入场门票”，但仍然是：

职业上限

第三阶段：用 AI 反向辅助学习

Tony 不是让你回去苦啃所有教材，而是建议：

在实战中遇到不会的，就借 AI 补基础。

这种学习方式更高效，也更有动机。

学霸理解

最值得记住的一句是：

AI 替你由 0 到 1 搬砖，而你需要负责由 1 到 100 的设计与把关。

十九、整篇答疑的底层主线

The Underlying Through-Line of This Entire Q&A

看似问题很散，但其实 Tony 一直围绕一个主线在回答：

AI 原生开发不是“把事情全交给 AI”，而是要学会把意图、规则、上下文、验证和回退组织起来。

你可以把这篇答疑压缩成五个关键词：

分层
边界
回退
验证
治理

二十、学霸速记表

Quick Revision Table

二十一、学霸总结

Top-Student Summary

这篇答疑的真正价值，在于帮我们把概念篇中最容易混淆的几个核心点彻底理顺。

首先，它明确了“规范”和“上下文”的关系：规范本质上也是上下文，但它属于约束型上下文，而代码、接口、Schema 等属于信息型上下文。这说明 AI 并不是简单地“看更多资料就更聪明”，而是必须同时得到两类输入：一类告诉它“现实是什么”，另一类告诉它“什么能做、什么不能做”。

其次，它帮助我们理解了 SDD 的分层本质：

• 需求错了，回 spec.md
• 架构错了，回 plan.md
• 实现错了，修代码

这意味着 SDD 不是一个僵化流程，而是一种支持按抽象层回退和纠错的工程结构。

再者，Tony 也非常务实地讨论了 SDD 落地时的现实问题：团队里不可能人人严格维护 Spec，spec-kit 目前也会显得笨重，上下文太长还会导致注意力衰减。这些问题都说明，真正重要的不是机械使用某个工具，而是掌握背后的思想：分层、治理、补偿、同步、控制粒度。

对于更复杂的有状态系统，Tony 特别强调了一个底线认知：

AI 负责生成，人类负责为数据安全兜底。

而在个人成长层面，这篇答疑也给出了 AI 时代非常关键的建议：
小白和转行者不应把 AI 当成替代思考的拐杖，而应把它当成加速实战、反向补基础的私教。
在这个时代，最危险的不是不会写代码，而是被 AI “喂废”，丧失主动思考、定义正确性和验证结果的能力。

因此，这篇答疑真正想告诉我们的，是：

AI 原生开发的核心，不在于“让 AI 帮你写”，而在于你是否能把意图、规则、上下文、测试、回退和团队治理组织成一个稳定的人机协作系统。

二十二、一句话记忆

One-Sentence Memory Hook

概念篇答疑的本质，是教你分清 AI 原生开发里的“意图、规则、上下文、验证与回退”各自处于哪一层。