星贸云航星贸云航 / 编码助手我的 Codex ↗

ENGINEER / 从能用到用得扎实

进阶工程实践

面向已有项目经验的开发者。围绕真实工程问题，减少无效尝试，让质量与成本都有依据。

下载实践手册 ↓← 返回学习路径

免费方法与模板 · 不包含自动代码审查或托管团队管理服务

PRACTICE / 01

复杂任务拆解

把“做一套权限系统”变成可以逐项验证的改动。

  1. 先写用户行为与验收边界，列出接口、数据、页面之间的依赖；不要按“前端一块、后端一块”盲目分工。
  2. 按可验收行为拆成小步：读取权限 → 控制访问 → 验证拒绝路径。每步写清输入、产物和谁依赖它。
  3. 确实独立的任务才并行；共享文件、迁移顺序和接口变更先约定负责人。检查接口后再合并，不能把多个“各自通过”当作整体通过。
留下什么

任务依赖表、每步验收、集成验证顺序。

试着做一次

以“管理员导出订单”为例，拆出权限判断、查询范围、导出结果三个步骤；说明无权限用户在哪一层被拒绝。

PRACTICE / 02

根因定位，而非反复猜测

遇到修了又坏的 bug，先补证据再改代码。

  1. 保留最小复现：版本、前置条件、输入、实际与预期结果。先确认能否稳定复现。
  2. 建立假设表：每个假设附支持证据、反例和一个能区分原因的检查。一次验证一个关键假设。
  3. 先让回归场景失败，再修根因并复查；若两轮尝试没有新证据，暂停扩大修改，重新缩小问题。这个阈值是实践建议。
留下什么

复现说明、被排除的假设、修复前后的验证记录。

试着做一次

为“偶发重复提交”列出前端重试、网络重放、服务端缺少幂等三个假设；用日志或测试区分它们。

PRACTICE / 03

让测试验证行为

避免 AI 写了实现，再写一组只会赞同实现的测试。

  1. 从验收条件独立列出正常、边界和失败场景；行为改动验证相关测试，文案小改动可做视觉检查。
  2. 业务边界使用接近真实的输入，确认关键检查不会被 mock 绕过；权限检查不能只验证按钮隐藏。
  3. 记录实际执行的命令、结果和未覆盖项。原有失败单独说明，不通过删断言或放宽校验让测试变绿。
留下什么

行为验证矩阵、真实运行结果、已知未覆盖项。

试着做一次

为“更新邮箱”检查格式错误、重复邮箱、未登录和正常更新；不要把接口返回200当作唯一成功条件。

PRACTICE / 04

把审阅放在关键路径上

代码能运行，不代表改动符合目标。

  1. 先读任务与验收条件，再看差异；检查无关重构、错误处理、兼容性和数据流。
  2. 可请 AI 从反例角度检查，但最终判断由人负责。高风险内容指定对应负责人，不用第二个模型的赞同代替审阅。
  3. 交付说明包含行为变化、证据、风险、回退方式。跨模块改动必须验证组合起来的用户流程。
留下什么

可操作的审阅意见与交付说明。

试着做一次

审阅一个缓存变更：查明失效时机、旧值读取、并发更新、回退后的行为，而不只看命中率。

PRACTICE / 05

管理上下文与调用成本

把预算花在相关信息上，不是每次重发整个项目。

  1. 提供相关路径、最小日志和必要约束；长任务结束一个阶段后整理已知事实、决定、待办与证据位置。
  2. 遇到偏离时先修正上下文；新会话承接精简摘要，并保留原始证据位置，不能把摘要中的推断当作事实。
  3. 先用日常档处理范围明确的任务；复杂推理仍卡住时再评估升档，记录原因与价格。缓存命中由实际账单确认，不能保证每次重用都享受缓存价。
  4. 为任务设人工预算与检查点。这里的预算模板不会自动限流或止损，实际费用以调用记录为准。
留下什么

上下文交接卡、任务费用与升级理由。

试着做一次

将一次长调试压缩成目标、事实、已排除假设、剩余问题四段，并检查哪些事实能追溯到日志或代码。

PRACTICE / 06

用一次完整练习串起来

示例：为现有列表增加筛选条件持久化。

  1. 约定刷新、翻页、清空筛选和旧链接行为，先确认 URL 参数或现有状态机制。
  2. 先实现一条最小完整路径，再覆盖空结果、非法参数和浏览器返回；不得为了演示重写整个路由。
  3. 对照差异、验证记录和人工审阅结论交付；记录实际耗时、调用费用及返工。
留下什么

一个带证据的交付包，而不只是生成代码。

试着做一次

用自己的项目完成练习。本文没有预填“测试通过”，也没有虚构提速百分比。

直接带回项目使用

下载拆解、排查与成本记录模板 ↓

带着模板，去做一次。

查看团队协作规范 →生成任务卡 →