2026 年，AI 编程工具已经足够强大——它可以写出可运行的代码、生成测试、重构模块。你的核心价值不再是写代码，而是想清楚要做什么、验证它是否做对了。
| 维度 | 旧时代 | AI 时代 |
|---|---|---|
| 代码生产 | 手写每一行 | AI 生成，人工审查 |
| 核心技能 | 语法记忆、API 熟练 | 需求拆解、验证能力、系统判断 |
| 犯错模式 | 写错逻辑 | 问题没想清楚、验证不够 |
| 速度瓶颈 | 打字速度 | 需求对齐速度 |
| 学习重点 | 学语言、学框架 | 学系统设计、学怎么提问 |
1. AI 不会帮你想清楚需求。 你给 AI 一个模糊的任务，它会给你一个模糊的结果。垃圾进，垃圾出。
2. AI 的输出必须被验证，不能直接上线。 AI 不会告诉你它写错了。验证是你的责任。
3. 你需要理解 AI 写的代码。 不能因为是 AI 生成的就不读。你要能解释每一行的作用，出了问题你要能定位。
4. 慢下来想，快起来做。 多花 30 分钟想清楚需求，可以省掉 3 小时的返工。
任何功能，不管看起来多简单，开始写代码之前必须有一份 PRD（产品需求文档）。这不是形式主义，是减少返工最有效的方式。
我们使用 AI 编程工具（Claude Code / Codex 等）作为主力开发工具。用好它，能让你的效率提升 3-5 倍。用错它，会带来更多 bug 和更多返工。
| 任务类型 | 适合程度 | 备注 |
|---|---|---|
| 写样板代码（CRUD、API handler） | 非常适合 | 提供清晰的输入输出定义 |
| 写单元测试 | 非常适合 | 给它验收标准，让它写测试 |
| 重构已有代码 | 适合 | 先有测试覆盖，再重构 |
| debug 错误信息 | 适合 | 把完整错误信息和相关代码一起给 |
| 写文档 / 注释 | 适合 | 告诉它面向谁写 |
| 系统架构设计 | 谨慎使用 | AI 给的方案要认真评审，不要直接采纳 |
| 数据库 Schema 设计 | 谨慎使用 | 必须人工 review，改 Schema 代价高 |
| 安全相关代码 | 必须 review | 认证、权限、加密，每一行都要看 |
给 AI 的 prompt 越精确，结果越好。参考这个格式：
# 背景
[当前代码库的相关背景，已有的数据结构]
# 任务
[具体要做什么，一句话到位]
# 输入 / 输出
[明确的输入格式和期望的输出格式]
# 约束
[不能改哪些、必须用什么库、性能要求]
# 验收标准
[写出测试用例，让 AI 同时写测试和实现]
# 不在范围
[明确不做什么，防止 AI 过度扩展]不要一次给 AI 太大的任务。把大功能拆成小模块，每个模块独立完成、独立测试，再组合。
测试不是功能写完后的补丁，而是开发过程的一部分。我们要求所有新功能采用 TDD 方式开发。
| 类型 | 覆盖率要求 | 说明 |
|---|---|---|
| 核心业务逻辑 | ≥ 90% | 排班算法、计费逻辑、权限判断等 |
| API Endpoints | ≥ 80% | 正常路径 + 主要错误路径 |
| 工具函数 | ≥ 85% | 重点测试边界情况 |
| UI 组件 | ≥ 70% | 主要交互 + 渲染测试 |
// 格式：[功能] should [期望结果] when [条件]
it('should return 401 when password is incorrect')
it('should lock account when failed attempts exceed 5')
it('should return empty array when no employees found')
it('should calculate total hours correctly with multiple shifts')所有代码在合并到主分支之前，必须经过至少一个其他人的 review。没有 review，不合并。
提交 PR 时，描述必须包含：
## 这个 PR 做了什么
添加用户登录接口，支持手机号+密码认证，返回 JWT token。
## 为什么这么做
当前没有认证机制，所有接口都是公开的。这是 MVP 的基础能力。
## 怎么测试
1. 正确账密 → 返回 200 + token（已测试）
2. 错误密码 → 返回 401（已测试）
3. 连续失败 5 次 → 返回 429（已测试）
4. 单元测试全部通过（截图附后）
## 潜在影响
- 后续所有需要认证的接口需要加 auth middleware
- Redis 需要提前部署| 检查项 | 说明 |
|---|---|
| 逻辑正确性 | 代码是否解决了 PRD 描述的问题 |
| 测试覆盖 | 关键路径有没有测试，边界情况有没有覆盖 |
| 安全问题 | SQL 注入、XSS、权限越界、敏感数据暴露 |
| 性能问题 | N+1 查询、不必要的循环、缺少索引 |
| 代码可读性 | 命名是否清晰，逻辑是否容易理解 |
| 错误处理 | 异常是否被妥善处理，错误信息是否友好 |
| 向后兼容 | 对已有接口的改动是否破坏了现有功能 |
对于复杂功能（超过 3 天的任务），完成一个模块后，用一个全新的 AI session 做 code review，不用做开发的那个 session。同一个 session 的 AI 有"确认偏差"——它会倾向于认为它写的是对的。
commit 信息是写给人看的，不是写给自己看的。三个月后，你或者其他人需要通过 git log 理解这段历史。
feature/[功能描述] # 新功能
fix/[问题描述] # bug 修复
refactor/[模块名] # 重构
docs/[文档名] # 文档更新
test/[测试描述] # 测试相关
# 示例
feature/user-authentication
fix/shift-calculation-overflow
refactor/schedule-engine# 格式
[类型]: [简洁描述]（不超过 50 字符）
[可选：详细说明，解释为什么这么做，不是做了什么]
[可选：关联 issue #编号]
# 类型
feat: 新功能
fix: bug 修复
refactor: 重构（不改变功能）
test: 测试相关
docs: 文档
style: 格式调整（不影响逻辑）
chore: 工具、依赖、配置
# 好的示例
feat: add JWT authentication for login endpoint
fix: prevent account lockout bypass via timing attack
refactor: extract shift validation into separate service
# 坏的示例
fix bug
update
wip
123
改了一点东西main 拉新分支"功能好像可以用了"不等于完成。以下是我们的完成标准。
| 标准 | 要求 |
|---|---|
| 可读性 | 另一个人不需要解释就能理解代码意图 |
| 命名 | 变量、函数、类名清晰表达意图，不用缩写（除非是通用缩写如 id、url） |
| 函数长度 | 单个函数不超过 50 行。超过则拆分。 |
| 注释 | 注释解释"为什么"，不解释"做了什么"（代码本身应该说清楚做了什么） |
| 错误处理 | 所有异步操作有 try/catch；所有外部调用处理网络失败；用户不看到原始错误堆栈 |
| 数据验证 | 所有外部输入在入口处验证，不信任任何来自前端或外部 API 的数据 |
| 日志 | 关键操作有结构化日志；敏感数据不写入日志 |
模糊的沟通是效率最大的杀手。学会说清楚你的问题、你的进度、你的阻塞点。
提问前，先自己查 10 分钟。查过文档、查过 stackoverflow、试过 AI 帮助，还解决不了，再问人。
每天结束前同步进度（站会 / 飞书群），格式：
今天完成：[具体完成的任务]
明天计划：[明天要做的事]
阻塞：[有没有被卡住的地方，需要什么帮助]阻塞点必须及时暴露，不要卡着不说，等到 deadline 才说"我被卡了好几天了"。
| 行为 | 原因 |
|---|---|
| 把 API key 或密码 commit 到代码仓库 | 不可逆，即使删掉也在历史记录里 |
| 在没有测试的情况下上线生产 | 没有测试 = 没有安全网 |
| 直接 push 到 main 分支 | 跳过 review，破坏协作流程 |
| 把 AI 的输出直接提交，不读不验证 | AI 会自信地给出错误答案 |
| 需求不清就开始写代码 | "简单功能因为假设不对浪费的时间最多" |
| 发现问题不说，等 deadline 才暴露 | 越晚说代价越高 |
| 生产数据库直接执行未测试的 SQL | 不可逆，没有回滚 |
| 在循环里执行数据库查询 | N+1 问题，会把服务器打挂 |
| 用 console.log 调试后忘了清理 | 生产日志污染，可能泄露数据 |
| 注释掉的代码不删，直接提交 | 代码库垃圾，用 git 找历史 |
| 忽略 linting 报错 | 每个警告都是潜在 bug 的预警 |
| 用中文命名变量和函数 | 国际惯例，保持英文 |
每次上线前，逐条检查，全部通过才能上线。
v1.0 · 2026-03 · Internal