核心功能与用法
Software Engineer 是一套为 AI 辅助编程场景设计的结构化代码生成规范。它定义了 AI 在编写、审查和重构代码时应遵循的七大核心原则：
1. Read Before Write — 强制要求 AI 先读取现有代码库，匹配既有的风格、命名约定和项目结构
2. Code That Compiles — 确保代码块包含正确的导入、使用实际存在的 API，杜绝占位符 TODO
3. Minimal First — 反对过早抽象，遵循 "三个具体案例才抽象" 的 YAGNI 原则
4. Errors as First-Class Citizens — 要求强类型错误、上下文日志、区分可恢复/致命错误
5. Boundaries and Separation — 明确 Handler/Service/Repository 三层架构的职责边界
6. Explicit Trade-offs — 架构决策必须记录选择理由、 trade-off 和回访条件
7. PR-Ready Code — 交付前检查清单：无死代码、函数<30行、无魔数、处理边界情况
显著优点
- 实用主义导向：区分 "Critical paths"（认证、支付、数据完整性，必须做对）与 "Experimental paths"（UI 特性、分析面板，快速迭代），避免过度工程化
- 可验证的质量标准：如 "Senior code reads like prose"、"The best code is boring" 等具象化原则，便于自检
- 架构决策模板化：强制要求用 "选择+理由+trade-off+回访条件" 四元组记录决策，降低技术债务
- 安全边界清晰：明确声明不存储数据、不发起网络请求、不访问项目外文件
潜在局限性与风险
| 局限/风险 | 说明 |
|-----------|------|
| **语言/框架中立性** | 规则为通用设计，具体语言的惯用法（如 Rust 的 Result vs Go 的 error）需开发者自行补充 |
| **静态规范** | 无法自动检测依赖版本变化，"Code That Compiles" 依赖 AI 的知识截止日期 |
| **主观质量标准** | "30秒让初级工程师理解" 等标准难以量化，依赖个人判断 |
| **无运行时约束** | 规则为建议性，不阻止 AI 生成违规代码（如无 try-catch 的裸调用） |
| **本地化缺失** | 全英文规范，非英语团队在术语理解上可能存在偏差 |
适合人群
- AI 应用开发者：构建代码生成 Agent 时需要内嵌的系统提示词
- 技术负责人：为新团队制定代码规范时可直接采用的基准框架
- 个人开发者：希望提升 AI 辅助编程输出质量的独立工程师
常规风险提示
- 建议将此 skill 作为 系统提示词（system prompt） 而非用户提示词使用，以确保约束效力
- 对于高度定制化的代码库（如大量使用内部 DSL），需额外补充领域特定规则
- 定期回访 "Explicit Trade-offs" 中记录的决策，避免临时方案长期固化