CRIPS的工程化开发方法六大典型问题的处理

CRIPS的工程化开发方法六大典型问题的处理

在实施 CRISP 原则（Context, Role, Issue, Scope, Preference）进行 AI 辅助开发（如在 Trae 平台中使用 GLM-4.7）时，尽管该框架能显著提升任务规划质量，但在实际操作中仍存在若干高频、易忽视的常见问题。这些问题往往导致 Plan 输出模糊、偏离目标，甚至引发无效或有害的代码修改。

以下是 CRISP 实施中的六大典型问题及其具体表现、根源分析与应对策略：

---

1. Context 模糊或缺失 → “AI 不知道你在哪个技术宇宙”

• 表现：

  • AI 建议使用 Vue 语法，但项目是 React；
  • 推荐 localStorage，但小程序环境不支持；
  • 忽略平台限制（如微信小程序主线程不能处理大图）。

• 根源：
  开发者默认“模型应该知道”，未显式声明技术栈、运行环境或架构约束。

• 对策：
  ✅ 强制填写 技术三元组：[框架] + [状态管理] + [运行平台]
  ✅ 对特殊限制加粗标注：“仅支持微信小程序基础库 2.20.0+”

---

2. Role 泛化 → “AI 以通用程序员身份思考”

• 表现：

  • 给出教科书式解决方案，忽略性能/兼容性；
  • 未考虑前端工程化规范（如未处理组件卸载）；
  • 建议引入新依赖，违反团队约定。

• 根源：
  角色描述为“开发者”“工程师”等宽泛称谓，未激活特定领域知识。

• 对策：
  ✅ 使用 复合专业角色：

  “你是一名熟悉 Taro 小程序性能瓶颈的前端架构师，特别关注异步状态与内存泄漏”
  ✅ 在 Role 中嵌入 质量属性优先级：如“稳定性 > 代码简洁性”

---

3. Issue 描述主观或不可观测 → “问题无法复现”

• 表现：

  • “试衣有时卡顿”“偶尔出错”；
  • 缺少触发条件、预期结果与实际偏差对比；
  • 未提供错误日志或用户路径。

• 根源：
  用体验性语言代替工程化问题定义，AI 无法构建因果链。

• 对策：
  ✅ 采用 When–Then–But–Should 四段式：

  When 用户快速连续上传两张图片（<500ms 间隔），
  Then 第二张的 loading 状态覆盖第一张，
  But 第一张请求完成后仍尝试 setState，
  Should 每次上传应独立管理状态并取消过期请求。
  

  ✅ 附上 控制台报错 / 用户操作录屏关键词

---

4. Scope 过宽或缺失 → “AI 试图重写整个系统”

• 表现：

  • Plan 包含“重构状态管理”“引入 Redux”等过度方案；
  • @SOLO Coder 修改了无关文件；
  • 修复一个 bug 却改动 5 个模块。

• 根源：
  未明确限定修改边界，AI 默认“最优解”可能涉及架构调整。

• 对策：
  ✅ 显式列出 允许修改的文件与函数：

  “仅限：src/pages/tryon/index.tsx (handleUpload, renderResult)”
  ✅ 使用 否定式范围声明：
  “不涉及后端 API、不修改公共组件库”

---

5. Preference 被忽略 → “生成理想但不可落地的方案”

• 表现：

  • 建议使用新库（如 RxJS），但团队禁止；
  • 采用实验性语法（如 React Server Components），不兼容当前构建链；
  • 未考虑测试覆盖率要求。

• 根源：
  开发者认为“AI 应该知道团队规范”，但模型无上下文记忆。

• 对策：
  ✅ 在 Preference 中明确 “必须 / 禁止”清单：

  - 必须：使用 AbortController 取消请求  
  - 禁止：引入任何新第三方依赖  
  - 必须：保持函数纯度，便于单元测试
  

---

6. CRISP 各要素割裂 → “整体逻辑不自洽”

• 表现：

  • Context 说用 Zustand，Role 却按 Redux 思维提建议；
  • Issue 要求最小改动，Plan 却设计全新 Hook；
  • Preference 要求高性能，但方案增加渲染层级。

• 根源：
  各要素由不同人编写或临时拼凑，缺乏一致性校验。

• 对策：
  ✅ 交叉验证法：写完 CRISP 后自问：

  • “这个 Role 是否能解决这个 Issue？”
  • “这个 Scope 是否足以实现 Preference？”
    ✅ 使用 模板强制对齐（见下文）

---

附：CRISP 自检 Checklist（实施前必查）

要素	检查项
Context	□ 是否包含框架、状态管理、平台、关键版本？
Role	□ 是否具体到技术领域 + 质量关注点？
Issue	□ 是否可用“当…时，出现…，但应…”复现？是否附错误信息？
Scope	□ 是否列出具体文件/函数？是否明确排除无关模块？
Preference	□ 是否有“必须/禁止”项？是否与团队规范一致？
一致性	□ 所有要素是否逻辑自洽？（如：Role 的能力能否在 Scope 内解决问题？）

---

总结

CRISP 不是填空题，而是工程思维的结构化表达。
常见问题的本质，是人类模糊认知与 AI 精确执行之间的鸿沟。
通过模板化输入、要素交叉验证与强制约束声明，可将这一鸿沟转化为高效协作的桥梁。