Appearance
Source-Driven Development 解决的是 AI 凭旧训练数据写框架代码的问题。它要求先确认项目依赖版本，再查官方文档，用当前版本推荐的写法实现，并把关键来源说明清楚。
AI 写框架代码总是过时怎么办：Source-Driven Development 怎么用
下载 source-driven-development 中文版 Skill ZIP
你让 AI 写一个 React 表单，它可能还在用几年前的写法。
你让它配一个 Next.js 路由，它可能混用旧目录和新目录。
你让它接一个 SDK，它可能写出一个看起来像真的、实际已经废弃的 API。
这类问题很常见。AI 的训练数据会过时，框架文档会更新，最佳实践也会变。
source-driven-development 这个技能的重点就是：不要凭印象写框架代码，先查源头。
什么时候必须查文档
不是所有任务都要查官方文档。
改错别字、改变量名、移动 Markdown 文件，这些不依赖框架版本。直接做就行。
这些场景更应该先查：
- React、Vue、Next.js、Svelte 这类框架写法。
- 表单、路由、数据获取、认证、状态管理。
- SDK 接入和第三方 API。
- 新版本迁移。
- 要写成项目模板或可复用模式的代码。
越是会被复制到多个地方的代码，越不能靠记忆。
第一步：先确认版本
查文档前，先看项目到底用什么版本。
Node 项目看 package.json，Python 项目看 pyproject.toml 或 requirements.txt，Go 项目看 go.mod，Rust 项目看 Cargo.toml。
不要直接问 AI：“React 表单怎么写？”
更好的问法是：
md
先读取 package.json，确认 React、Vite 和相关表单库版本。
再查当前版本官方文档。
按官方推荐写法实现，不要用训练数据里的旧写法。版本不同，答案可能完全不同。
第二步：只查相关页面
查文档不是把整个官网扔给 AI。
你要查的是具体页面。
比如要写 React 的 action 表单，就查 React 对应 hook 或 action 文档；要写 Vite 配置，就查 Vite config 文档；要写 Django auth，就查 Django 当前版本 auth 文档。
不要拿 Stack Overflow、博客、教程当主要依据。那些内容可能有用，但它们不该排在官方文档前面。
资料优先级可以这样排：
- 官方文档。
- 官方博客、迁移指南、changelog。
- MDN、web.dev 这类标准资料。
- 社区文章，只能作为补充。
AI 可以总结资料，但不能用“我觉得应该这样”代替来源。
第三步：按文档实现，不要只贴链接
有些 AI 会查了文档，然后仍然写旧代码。
所以你要让它明确说明：这个实现对应文档里的哪个模式。
比如：
md
实现时请说明：
- 当前项目检测到的库版本。
- 使用了哪份官方文档。
- 哪个 API 或模式来自文档。
- 有没有和项目现有写法冲突的地方。如果官方文档和现有项目写法冲突，不要让 AI 偷偷选一个。
它应该停下来告诉你：文档推荐 A，项目里现在普遍用 B。你再决定是跟随项目风格，还是趁这次改成新写法。
查不到文档怎么办
查不到就是信息。
这可能说明：
- 这个写法不是官方推荐。
- 这个库文档质量很差。
- 你搜错了版本或入口。
- 这个 API 已经被移除。
这时 AI 不应该硬写一个很自信的方案。
更稳的说法是：
md
我没有找到当前版本官方文档支持这个写法。
可以继续实现，但需要把它标成未验证方案。
如果这是生产代码，建议换成官方文档覆盖的模式。承认没查到，比编一个答案安全。
古法编程怎么用这个技能
古法编程强调透明可控。
Source-Driven Development 正好补上 AI 编程的一个薄弱点：让每个框架相关决策都能追溯到来源。
你不用盲信 AI，也不用盲信自己记忆。看版本，看文档，看实现是否对应。
这会慢一点，但会少很多“跑起来才发现 API 不存在”的坑。
你可能还需要
同类技能：
如果你正在写框架、SDK 或平台相关代码，先让 AI 查官方文档，再让它动手。