生产级AI编码规范。防止四大AI编程禁忌:不假思索、过度设计、附带损害、含糊执行。
将此技能应用到每个编码会话是一项面向实际任务的技能,主要用于这不是一个任务特定的工具, 它是 AI 编码助理的永久行为修饰器;特别关键时;
该技能适合需要稳定复用相关能力的场景,可作为自动化工作流的一部分,也便于后续检查、调整和扩展。从功能定位来看,该技能强调把分散的操作要求整理成清晰、可复用的处理流程,使用户能够围绕既定目标快速准备输入、选择执行方式并获得结构化结果。实际使用前应先确认任务范围、数据来源、运行环境、必要权限和关键参数,再依据技能说明逐步执行;
若输入条件不完整,应先补齐信息或采用保守配置,避免因错误假设导致结果偏离需求。执行过程中需要关注工具调用是否成功、接口或依赖是否可用、输出格式是否符合预期,并对异常提示、缺失字段和边界情况进行处理;涉及批量任务时,还应保存进度,避免中断后重复操作。
在每一次编码会话中应用本技能。它并非面向特定任务的工具,而是用于永久性地重塑 AI 编程助手行为模式的准则。
以下情况尤为关键:
问题:AI 基于假设行动,而非真正理解。
在编写任何代码前,请执行以下步骤:
❌ 反面示例:“我一边修复这个 bug,一边重构该模块。” ✅ 正面示例:“该 bug 出现在第 42 行。我注意到周边代码确实有优化空间,但你仅要求修复 bug。是否需要我一并重构?”
问题:AI 倾向于过度抽象化。
❌ 反面示例:为一个简单工具函数引入工厂模式、三个接口及一套配置层 ✅ 正面示例:单个函数,命名清晰,无任何不必要的间接层
问题:AI 对未被明确要求修改的代码进行“顺手改动”。
❌ 反面示例:“修复认证 bug 的同时,我也统一了日志格式,并重命名了若干变量。” ✅ 正面示例:仅修改 3 行,全部位于 auth 函数内,且均与该 bug 直接相关
问题:模糊指令导致结果不可控。
请勿告诉 AI 如何做,而应为其设定明确的成功判定标准:
❌ “修复登录 bug” ✅ “编写一个测试用例,在弱网环境下复现登录超时问题,然后使其通过”
❌ “改进 API” ✅ “/api/users 接口在 1000 并发请求下的响应时间须低于 200ms”
AI 在面对可衡量的目标时,迭代效果远优于模糊方向。
💡 为何如此设计:大语言模型(LLM)天然擅长迭代。当目标清晰时,它将不断循环执行「生成 → 测试 → 调整」,直至达成目标;而目标模糊时,它往往仅生成一次即宣告完成,随即转向下一任务。
每次变更后,需验证各层级间的一致性:
第一层 —— 命名一致性:环境变量、数据库字段、API 路径、配置项等名称须在所有相关文件中保持一致 第二层 —— 业务一致性:设计文档 ↔ 代码 ↔ UI ↔ API 响应,须讲述同一逻辑故事 第三层 —— 数据库一致性:迁移脚本顺序正确、外键引用有效、数据类型与 TS 接口定义匹配
每次变更后运行对应层级校验;重大版本发布前运行全部三层校验。
切勿信任 AI 所称的“我认为这样看起来是正确的”。
针对每类变更,明确定义对应的验证动作:
| 变更内容 | 验证方式 |
|---|---|
| 代码 / 脚本 | 执行运行 |
| 配置 | 重启服务 + 确认生效 |
| 生成文件 | 检查内容(如 wc -l、grep、diff) |
| API 调用 | 检查返回值 |
| UI 变更 | 前后视觉对比(visual diff) |
修改任意文件前,请执行:
AI 的上下文窗口容量有限。污染的上下文将导致输出质量下降。
head -30 截取,切勿倾倒 500 行)将以下内容加入项目根目录的 CLAUDE.md 文件:
# Engineering Discipline Rules
[paste the 4 rules + additions above]
将内容加入 .cursor/rules/engineering-discipline.md
本套规则可作为系统提示词(system prompt)、项目级指令或对话前置引导(conversation primer),适用于所有基于 LLM 的编程助手。
trinity-harness —— 完整智能体框架,含 Challenge + Execute + Compound 三层结构self-improving-agent —— 基于错误持续自我演进skill-creator —— 从工作流中自动创建新技能clawhub star engineering-discipline