我把“AI 编程八荣八耻”做成了一个可安装的 Coding Agent Skill

AI 编程常犯的毛病，其实缺的是一套规矩

现在用 AI 写代码的人越来越多，像 Codex、Claude Code、Cursor 这些工具确实能省不少事。但实际用起来，总有些让人哭笑不得的问题：

• AI 根本没看项目代码，上来就改；
• 看到函数名就猜接口，结果项目里压根没有；
• 需求没说清楚，它自己脑补一套业务逻辑；
• 修个小 bug，顺手把整个模块重构了；
• 代码写完就宣布任务完成，连跑都没跑过。

这些问题，往往不是模型不会写代码，而是缺少一套明确、稳定、可执行的工程协作规范。于是，有人把网上流传的“AI 编程八荣八耻”认真梳理了一遍，做成了一个可以直接安装的 Coding Agent Skill——Scientific Coding（科学 Coding 观）。

这到底是个什么东西？

scientific-coding 不是一个普通的提示词（Prompt），也不是某个编程框架。它是一套专门给 AI 编程 Agent 用的工程行为规范。简单说，它的目标不是让 AI 一次吐出更多代码，而是让它写得更谨慎、更可靠，更贴近真实软件开发的流程。

核心就三句话：

先读上下文，再写代码。
先确认事实，再调用接口。
先验证结果，再宣布完成。

为什么需要这套规范？

举个例子，你让 AI 给订单页面加个状态筛选功能，它可能直接写出 client.orders.filterByStatus(status)。但你的项目里可能根本不存在这个方法。正确的做法应该是：

1. 先搜索项目里已有的订单相关接口；
2. 查看请求是怎么封装的；
3. 确认状态字段到底叫什么；
4. 参考其他页面类似功能的实现；
5. 在现有结构里做最小改动；
6. 最后跑一下测试或构建命令。

Scientific Coding Skill 的作用，就是把这些工程师的日常习惯，变成 AI Agent 能读懂、能执行的硬性规则。

核心理念：少点幻想，多点查询

这套规范的核心可以总结为：少一点幻想，多一点查询；少一点猜测，多一点确认；少一点生成，多一点验证。具体拆解成八条：

1. 先理解，再修改

动手改代码前，必须先搞清楚项目的整体情况：结构是怎样的、模块各自负责什么、数据怎么流动、调用链路如何、有没有现成的实现方案、团队有哪些约定。不能只盯着一个文件就开始大刀阔斧地改。

2. 不编造 API

所有用到的接口、参数、返回值、文件路径、数据结构，都必须有据可查。来源可以是项目源码、类型定义（TypeScript/Pydantic）、官方文档、API 文档、测试用例，或者直接问用户确认。绝不能因为某个名字“听起来合理”就假设它存在。

3. 不擅自决定业务规则

当需求模糊时，比如“隐藏不可用商品”，AI 不该自己决定“不可用”是指没库存、未发布、已禁用还是区域限制。正确做法是先在代码库里找找有没有现成的定义，实在找不到再向用户提问。

4. 优先复用已有代码

要新增功能时，脑子里的优先级应该是：已有代码 > 已有组件 > 已有工具 > 扩展现有模块 > 全新实现。能不重复造轮子就不造，避免创建一堆功能雷同的新接口。

5. 小步修改

只改完成当前任务必需的部分。修登录按钮就别去动认证模块，也别为了追求“代码高级感”而引入不必要的抽象层或新依赖。

6. 尊重项目架构

AI 必须遵守项目既定的规矩：目录怎么分、变量怎么命名、模块边界在哪、代码风格如何、用了哪些技术栈、遵循什么设计模式。不能为了图省事就跨层调用或绕过现有封装。

7. 考虑异常、安全和边界

除了正常流程，还得想到各种意外情况：传入空数据怎么办？网络请求失败了怎么办？用户没权限怎么办？资源不存在怎么办？更要警惕密钥泄露、SQL 注入、命令注入、越权访问这些安全问题。

8. 完成后必须验证

代码生成完毕，绝不等于任务结束。AI 应该尽量去跑单元测试、集成测试、类型检查、代码 lint 或构建命令。如果实在没法自动验证，也得明确告诉用户原因和潜在风险。

从“八荣八耻”到“十六荣十六耻”

在原有基础上，这套规范被扩展成了十六条更具体的行为准则：

不猜接口，先查文档。不糊执行，先问边界。不想业务，先做人类确认。不造轮子，先复用已有。不跳验证，先写测试。不破架构，先守规范。不装理解，坦白未知。不乱修改，谨慎重构。不看局部，先懂全局。不求一步，先做迭代。不忘安全，先做防护。不堆复杂，保持简单。不漏异常，考虑边界。不改旧物，先懂原因。不留黑盒，补充文档。不卷代码，追求质量。

这十六条基本覆盖了 AI 在真实项目中最容易踩的工程坑。

项目长什么样？

这个 Skill 的代码仓库结构很清晰：

复制Scientific-Coding/
├── README.md
└── scientific-coding/
    ├── SKILL.md          # Skill 入口和主流程
    ├── RULES.md          # 完整规则说明
    ├── CHECKLIST.md      # 修改前/中/后的检查清单
    ├── PROMPTS.md        # 可直接复制的提示词
    ├── agents/
    │   └── openai.yaml   # Agent 调用元数据
    ├── examples/         # 正确和错误案例
    │   ├── correct_workflow.md
    │   └── hallucination_cases.md
    └── templates/
        └── task_report.md # 任务报告模板

怎么安装和使用？

这个 Skill 已经能被 skills CLI 工具识别。安装也很简单：

复制# 先看看仓库里有什么
npx skills add visionlmlm/Scientific-Coding --list

# 安装到 Claude Code
npx skills add visionlmlm/Scientific-Coding --skill scientific-coding -a claude-code -g -y

# 安装到 Codex
npx skills add visionlmlm/Scientific-Coding --skill scientific-coding -a codex -g -y

安装好之后，在 Claude Code 里就可以这样调用：

复制/scientific-coding 请分析当前项目结构，不要修改任何文件。

或者执行具体任务：

复制/scientific-coding 请修复当前登录接口报错。先搜索现有接口和调用方式，不要编造 API，完成后运行相关测试。

甚至可以用自然语言触发：

请按科学 Coding 观处理这个任务：先读上下文，不编造 API，小步修改，并完成验证。

它能解决什么问题？

这个 Skill 不会提升模型本身的代码能力，但它能有效约束 AI 的工程行为：

• 大幅降低编造接口的概率；
• 减少无关的、破坏性的代码修改；
• 避免过度重构带来的新问题；
• 提高对现有代码的复用率；
• 强化测试和验证的意识；
• 让任务结果更具可解释性；
• 明确区分“已确认事实”、“推测”和“未知”。

说白了，它更像一套给 AI Coding Agent 用的“工程制度”，而不是一个简单的提示词模板。

适合用在哪些场景？

这套规范特别适合以下任务：

• 日常的 bug 修复；
• 小功能的增量开发；
• 前后端接口联调；
• 代码审查（Code Review）；
• 项目结构分析；
• 重构方案的设计与评估；
• 补充单元测试或集成测试；
• 进行基础的安全审查；
• 在团队内部统一 AI 编程的行为标准。

对于支付系统、权限管理、数据库迁移这类高风险的核心模块，这种强调谨慎、验证和尊重架构的行为规范就显得尤为重要。

结语

AI 编程工具正在从“代码生成器”演变成“工程协作者”。一个靠谱的协作者，光会写代码是不够的，还得有查询事实的习惯、理解上下文的能力、尊重架构的意识、控制修改范围的原则、主动验证的流程，以及坦白自己不知道的诚实态度。

Scientific Coding 想解决的，正是这个问题：让 AI 不再看起来很聪明地瞎写，而是更像一个靠谱、谨慎、可验证的工程伙伴。

项目已经开源在 GitHub，欢迎大家一起完善。