LLM应用

很多人以为构建 Agent 系统，最难的问题是"让 LLM 更聪明"。真正进入生产环境，你会发现把你逼疯的不是模型效果，而是模型的“不确定性”。

通过 SDD + OpenSpec，我们在一个真实的存量项目中，用 AI 生成了 9600+ 行可编译、可测试的代码，手动修改不到 50 行。本文记录了完整的实践过程、评测结果和踩坑经验。

写个Skill 一天就能上线，但生产级的Skill你会发现远没有那么简单。Skill 设计不是 prompt 工程，而是一门系统工程

OpenSpec 架构 整体架构 可以把它理解成三层： 状态层：仓库目录本身就是状态存储 计算层：schema + dependency graph + validator 交互层：CLI 和 skills，把结构化状态喂给 AI 或人 这套分层很重要，因为它避免了一个常见问题：把“流程”硬编码进 prompt。在 OpenSpec 里，prompt 只是表现层；真正的工作流定义在 schema 中，真正的状态在文件系统里。 核心对象 OpenSpec 其实有4个核心对象： specs：当前系统行为的 source of truth changes：待合入的变更包 schema：工作流定义，决定有哪些 artifact、它们如何依赖 archive：变更完成后的历史沉淀 如果第一次使用，你可能会好奇schema是什么? 在每次变更文件夹中，.openspec.yaml文件中就有 schema字段，默认值为spec-driven。可以在源码中，看到spec-driven定义了产出物（artifacts）的目录、文件名、文件格式、生成Prompt等，以及实施阶段（apply）读取的任务文件和Prompt。 这是OpenSpec预定义的schema，我们也可以自定义schema，对他进行扩展。 工作流 如下是OpenSpec默认的工作流，通过schema定义中的requires字段定义依赖关系。 flowchart LR proposal --> specs proposal --> design specs --> tasks design --> tasks tasks --> apply apply --> archive artifacts: - id: proposal generates: proposal.md requires: [] - id: specs generates: specs/**/*.md requires: [proposal] - id: design generates: design.md requires: [proposal] - id: tasks generates: tasks.md requires: [specs, design] apply: requires: [tasks] 这里的设计哲学：dependency is an enabler, not a gate。 也就是说，依赖表示“现在什么是可做的”，而不是“你必须严格按唯一顺序前进”。这和很多传统 spec 流程差异很大：后者把流程建模成 phase，前者把流程建模成 action + dependency。 ...

作为一名架构师，我经常被问到一个问题：“你的系统是怎么做到连续两年没有出过 P0/P1 级故障的？"。我们确实做了很多事情，但是一直没有进行系统的梳理，想趁此机会把思考、尝试讲出来。

ing…