技术规划不是让 Agent 在一张白纸上决定整个系统。如果不给 Spec Kit 任何技术背景，那么它将给出一份你完全预想不到的技术规划。比如，你想用的是 Python，它却选择了 Node.js。所以，用户需要先给出必须遵守的限制，说明自己的技术偏好，再把尚未决定的问题交给 Phase 0 调研。这一节以飞书为例，完成胶囊系统进入 Plan 前的最后准备。
2.1 技术决策的职责边界
SPEC 之所以不去提前规定数据库、框架和接口，是为了保持需求的独立性，不是要把所有技术决定都交给 Agent。对一个还没有代码的新项目来说，如果连运行环境、首选平台和可以接受的复杂度都不限定，Plan 的决策范围就会太大。Agent 可以生成一套内部自洽的方案，但这套方案未必符合用户现有的工具、维护能力和使用习惯。
工程上更合理的分工是：人先提供自己已经掌握的技术背景，Agent 帮助整理，最后由用户确认哪些不能改、哪些只是偏好，以及哪些可以交给 Plan 调研。因此，下面的三类内容是进入 Plan 前的输入分类，不是 Plan 执行完成后才得到的三种结果。
| 进入 Plan 前的技术背景 | 用户表达的意思 | Plan 如何处理 |
|---|---|---|
| 已经确定的硬约束 | “这个条件不能改。”例如，系统必须在某个环境中运行，或者必须遵守既定的数据边界 | 将它当成方案边界，不得擅自替换，并在宪章检查中确认方案没有违反它 |
| 用户的技术偏好 | “我希望优先这样做，但如果确实不可行，可以提出其他方案。” | 将它变成 Phase 0 的验证对象，调研后决定接受、部分接受还是放弃该偏好 |
| 交给 Plan 的开放问题 | “这个技术选择我还没有答案。”例如，使用文件还是数据库，采用什么模块结构 | 比较可行方案，在 research.md 中记录最终决定、理由和考虑过的替代方案 |
以上输入不是标准分类，实际上这是我做 Vibe-Coding 的一些心得。所以他没有一个标准模板，只是我建议大家在做技术选型的时候按照这个思路分类。
你完全可以先用自然语言描述，比如：
我想用 Hermes 来做语义识别和意图分析，数据放在飞书，但还没想好用文档还是多维表格。
Codex 应该把这句话整理为三类信息，然后再请用户确认：Hermes 是否必须使用？飞书是必须使用，还是优先考虑？文档和多维表格的取舍是否交给 Phase 0 调研？
但是我依然不建议同学们用零散的 Prompt来输入这些技术栈，这一点请参考后面的”Planning Brief"。
2.2 充分利用 Agent 的能力做技术选型
现在，我们稍微停一下。思考下哪些是我们能决定的，哪些是模糊的。比如，我相信用什么语言开发，你一定有你自己的想法。
你不会让 Agent 来帮你选语言吧？大可不必。胶囊系统现在已经决定使用 Python，这就是 Plan 必须遵守的技术约束。
但飞书呢？虽然我们在需求分析里提到过飞书，但我相信绝大多数同学对飞书的相关功能并不了解。我们可以先确定使用飞书，再在 Plan 阶段交给 Codex 调研飞书文档、知识库和多维表格分别能承担什么。这也是我们在 SPEC 里并不涉及具体技术的好处——如果在 SPEC 阶段就要考虑技术，我们很可能会陷入技术调研中而无法想清楚需求。
我们现在已经确定用 Python 开发胶囊系统，由 Agent 基座处理资料，并用飞书保存和展示长期数据。本教材使用 Codex 开发，用 Hermes 验证基座兼容性，但胶囊系统本身不能绑定某个基座。另一方面，“确定使用飞书”不等于“飞书的每项能力都已经被证明能够满足需求”。如果只在指令中写一句“使用飞书”，Agent 可能会直接开始设计，而不再核对飞书的具体能力。
因此，本次 Plan 不再讨论是否使用 Python、Agent 基座和飞书。Phase 0 需要把 SPEC 中的用户故事和功能需求映射到三者的职责，设计 Codex 与 Hermes 都能使用的 Skill 和 CLI 契约，再核对飞书文档、知识库、多维表格与开放平台的 API、授权范围、调用限额和事件机制。
调研结果必须区分哪些需求可以直接满足，哪些需要额外开发，哪些暂时无法实现。
如果飞书无法满足某项关键需求，Plan 不能悄悄删掉需求，也不能擅自引入另一套平台。它应该记录能力缺口和替代方案，说明分别会影响哪些需求、使用方式和开发成本，然后把决定交还给用户。