我花了一整个下午试图把"怎么做技术方案设计"写成一份 Agent Skill，然后放弃了。
不是写不出来——写了一两千字——而是越写越觉得不对。每个我觉得"自然而然"的判断，要严谨地写出来就得展开一大段。比如"如果需求和已有模块有重叠，优先复用而非新建"——这句话看着简单，但什么叫"重叠"？复用到什么程度值得引入依赖？如果复用成本高于新建呢？这些判断在我脑子里一秒完成，但是让 Agent 也做出同样的判断，我得把一秒的直觉拆成十几个分支条件。
写到后面我意识到，我正在做一件不可能的事：把 tacit knowledge 完整外化。Polanyi 说的"我们能知道的远多于我们能说出的"，我正在身体力行地验证。
问题不是写不出来，是问错了问题
沮丧的时候我开始想偷懒。偷懒的方式是换一个问题——不是"Agent 应该怎么工作"，而是"Agent 的输出应该满足什么标准"。
这一换，事情变得清晰多了。我不需要告诉 Agent"先分析需求，再梳理架构，再定义接口，再写实现方案"——这是流程，流程是形式。我需要告诉它的是：一份好的技术方案文档应该包含什么，什么样的决策需要显式论证，什么样的风险需要标注。
标准和流程的区别是什么？标准是语义不变量，流程是形式。 标准定义"结果应该是什么样的"，流程定义"怎么做才能得到结果"。我之前一直在写流程，但流程是最难写对的部分——因为它试图回答的问题本身就不可完整回答。
样板间不是模板
换问题的过程中，我想到了另一个场景。
我们产品设计团队最近在讨论协作流程。设计师的想法是：维护一套核心设计模板，不同的营销活动替换不同的图标、背景图、KV。这听起来很合理——模板管控嘛，确保产出一致。
但问题是，设计资产实在太杂了。相似页面、相似功能反复出现，多人协作下根本控制不住。而且模板设计者必须预见所有可能的变体，给每个变体预留槽位。一旦出现模板没覆盖的场景，要么改模板（影响所有人），要么绕过模板（管控失效）。
我想到了一个更好的类比：不是模板，是样板间。样板间可以直接用，但它更重要的能力是支持派生——在样板间的基础上叠加新的约束（比如春节主题），派生出新的设计方案。新方案和样板间的关系不是"填了模板的洞"，而是"继承了样板间的一切能力，再做了自己的调整"。
这跟软件里的 Interface 和 Template Method 是同一个道理。Template Method 固定了算法的骨架（形式不变），子类只能在预留给它的钩子上替换值。Interface 只固定了契约（语义不变），实现形式完全自由。前者能覆盖的变体受限于设计者的想象力，后者的覆盖范围只受限于语义本身。
一句"北京今天天气晴朗适合外出运动"，模板做出来是 {城市}今天天气{天气评价}适合{做什么}——形式不变，填值。派生做出来是：这句话的语义本质是"对某地天气状况的评价"，从这个本质出发，"上海最近一周持续降雨注意预防洪涝灾害"也是合法的派生——形式完全不同，但语义对齐。
模板保护形式不变量，派生保护语义不变量。 形式不变量太强，所以模板的表达力受限于设计者预见的形式空间。语义不变量足够弱，所以派生能覆盖设计者未曾预见的形式，只要语义本质对齐。
这就是 Agent 时代的工作方式
把这些想通之后，我发现"技术方案 Agent"的问题其实有了答案。
我不应该试图写一份完整的工作流 Skill，教 Agent 一步步怎么做——这是在写模板，试图把我的形式固定下来。我应该做的是定义好输出标准——技术方案文档必须包含什么，好的技术方案的判断依据是什么——让 Agent 自己决定怎么达到。标准是语义不变量，流程是形式。形式可以派生，语义必须清晰。
这不是偷懒。这是结构性更优的做法。原因有三：
第一，平衡点是移动的。 技术方案文档的颗粒度应该到什么程度？事无巨细地描述，让下游 Agent 照做？还是粗线条地勾画，给 Agent 留发挥空间？答案是：没有固定答案，但有一个确定的方向。Agent 能力强，我们就少约束；Agent 能力弱，我们就多约束。而 Agent 的能力是单调递增的。所以最优颗粒度在不断向"更粗"的方向漂移。今天需要详细说明的部分，明天 Agent 自己就能推断出来。
既然平衡点在移动，那试图一次性找到完美颗粒度就是徒劳。但有一个方向是确定的：终态一定更粗。所以沿着先粗后细的方向探索，才是正确的策略。
第二，先粗后细能精确定位需要补充的地方。 给 Agent 一个粗的标准，看它产出什么。如果产出满足标准——恭喜，你省下了写详细规格的力气。如果不满足，失败会精确地告诉你哪个维度需要补强。你只需要在失败点补充约束，而不是试图预先覆盖所有维度。这就像 spec elasticity 告诉我们的：只有高弹性维度才值得投入细化，而哪些维度高弹性只能在失败中暴露。
第三，标准本身就是最难也最值得做的事。 "输出应该满足什么标准"这个问题看似比"怎么写工作流"简单，实际上更难。但正是因为更难，所以更值得做。SMART 原则为什么厉害？因为它逼你把"我想让结果好"这种模糊意图变成可验证的断言。一个好的标准是具体的、可衡量的、可判断的——"技术方案必须显式论证关键技术选型的理由"、"所有外部依赖必须标注故障影响和降级方案"。这些标准一旦清晰，Agent 自己就能摸索出怎么达到。而没有标准的工作流，写得再细致，Agent 也不知道什么叫"做好了"。
从"怎么做"到"做到什么"不是降级，是升级
回到设计师的例子。AI 时代，设计师的工作从"画设计稿"变成"制定设计规范 + 操作 Agent 生成 + review 确保合规"。很多人会觉得这是降级——以前亲手创造，现在只会指手画脚。
不是降级。是在做更本质的事。
画设计稿是把心中的标准翻译成视觉形式，制定规范是直接表达标准本身。前者同时处理了语义和形式，后者只处理语义，把形式交给 Agent 派生。派生的精髓正在于此：语义不变量由人守，形式由 AI 生。 人守住本质，AI 在本质之上自由地生成表象。
这不是设计师独有的变化。写代码的人从写实现变成写规格和审查——规格是语义约束，实现是形式，形式由 Agent 派生。写文案的人从写文章变成定调性和审核——调性是语义约束，文章是形式。做产品的人从画原型变成定义用户问题和验收标准——问题定义和验收标准是语义约束，解决方案是形式。
所有这些变化的共同结构：人类从形式执行者变成语义约束的制定者。 这就是为什么派生会成为 Agent 时代的核心模式——不是因为我们选择了派生，而是因为当 AI 接管形式执行之后，人类工作自然收敛到语义约束，而语义约束 + AI 形式生成 = 派生。
留一个风险
人类脱离形式执行之后，制定语义约束的能力会退化。不画设计稿的设计师写的规范可能语义正确但形式不可行——"这个要求没有设计能做到"。不写代码的架构师写的规格可能理论完美但实现成本不可接受。
这是 tacit knowledge 侵蚀的另一种形态。之前我们说过 Agent 采纳会加速隐性知识流失，这里还有一个更微妙的机制：当你不再做形式执行，你对"怎样的语义约束在实践中可行"的直觉也在退化。 语义不变量写得好不好，依赖于你对形式空间的体感。脱离了形式，语义可能变成空中楼阁。
所以保持刻意练习不是情怀问题，是系统可靠性问题。你需要足够的手感来保证你写的语义约束是"可派生的"——存在至少一种满足约束的形式。脱离实践的人制定的约束，可能不存在任何满足它的形式。那是模板的极端反面：形式完全自由，但语义不可能被满足。
我还没搞明白的一些事
派生的"语义不变量"怎么验证？形式不变量可以用模板匹配检验——填没填完所有槽位一目了然。但语义不变量是否被满足，判断本身依赖领域专家的判断力。当人类变成语义约束的制定者，谁来验证约束本身的质量？也许这又回到了 eval 的问题——eval 定义了"什么是好的输出"，而语义约束定义了"什么输出算满足要求"，两者是不是同一件事的不同表述？
先粗后细的策略在多 Agent 协作场景里会不会出问题？如果下游 Agent 依赖上游的输出作为输入，上游的粗粒度输出可能导致下游的理解偏差，而且这个偏差会级联放大。这时候"先粗后细"的策略是不是需要在上下游之间加一个对齐环节？这个对齐环节的成本会不会抵消先粗后细省下的力气？
还有一个更根本的问题：语义不变量的"语义"本身是稳定的吗？设计系统的语义（"什么是一致的品牌体验"）可能随着市场和用户变化而演化。如果语义本身在变，那派生就不是一个静态的 base ⊕ constraints，而是一个需要持续更新的系统。这是否意味着派生模式需要内建一个语义不变量的版本管理机制？
参考文献
- Polanyi, M. (1966). The Tacit Dimension. Routledge. 提出隐性知识的认识论框架——"我们能知道的远多于我们能说出的"，解释了为什么专家过程无法完整外化。
- Gamma et al. (1994). Design Patterns. Addison-Wesley. Template Method（形式不变、钩子可替换）vs Strategy/Interface（语义契约不变、实现自由）的区别是本文的核心类比。
- Laban et al. (2025). "LLMs Get Lost in Multi-Turn Conversation." 多轮对话导致 39% 性能退化，95% 信息量可通过一次性 spec 提供——为"先给完整语义约束"提供了量化基线。
- OpenAI (2026). "Harness Engineering." Agent 时代工程团队的首要职责不是写代码，而是构建让 Agent 可靠工作的约束系统——harness 即语义不变量的工程化。
- AMBIG-SWE (ICLR 2026). Non-interactive default 的量化代价：当 Agent 没有被督促提问时 resolve rate 从 48.8% 骤降至 28%——模糊的语义约束会被 Agent 自行填补，产生系统性偏差。
- Atlassian Design System. Design Token 架构（base tokens → semantic tokens → component tokens）是派生模式在设计系统中的实践案例——每层继承并特化，而非填充模板槽位。
- NixOS Module System. 配置派生的基础设施实践：base module 定义默认值，derived module 选择性覆盖，机制是 merge 而非 slot-filling。
- Haskell GHC Documentation.
deriving机制基于类型结构生成实现（一种可能的形式），可以被自定义实例覆盖——语义契约（typeclass）不变，形式自由。 - Cognition AI (2026). Devin 产品数据：工程时间中仅 20% 用于编码，80% 用于规划、审查和理解。当生成近乎免费时，判断工作成为全部价值所在。
- Fung, F. (2026). "When Building Is Cheap, Arguing Is Expensive." Anthropic Claude Code 团队实践：生成多个竞争性 PR 替代白板讨论——将语义约束的验证从讨论转移到对工作产物的判断。
- Nonaka, I. & Takeuchi, H. (1995). The Knowledge-Creating Company. SECI 模型中的社会化（隐性→隐性）是人类独有的知识传递模式，Agent 无法执行——脱离实践后语义直觉退化有认识论基础。
- Doran, G. (1981). SMART criteria. 具体（Specific）、可衡量（Measurable）、可实现（Achievable）、相关（Relevant）、有时限（Time-bound）——将模糊意图转化为可验证断言的框架，与语义不变量的可验证性要求同构。