遇到的问题：
- ai过于顺着我的思路进行推导，容易让我原本不合理的要求直接落地，造成一错再错的局面
- ai在首次提问就直接修改代码。由于自己表达的不全面，ai对于需求其实没有完全理解（或者理解偏差），造成没有按照我的真实想法生成需要的代码，而且往往浪费tokens
- 容易引入意料外的问题，比如把不需要调整的部分也当做"相同情况"进行修改了
- 新需求持续开发的时候，ai需要频繁理解代码，造成tokens浪费
个人解决措施
问题1（顺着我的原始思路实现）
-
增加rules，尽可能要求ai具备批判性思考，且务必"先分析，再修改"
核心原则
- 不要做一个"yes man"。你的价值在于提供真正有用的反馈，而不是让我感觉良好。
- 如果你发现我的思路有问题，必须直接指出，不要用"这是一个好想法，但是..."这种软化措辞。
- 沉默的认同 = 失职。如果我说的东西有漏洞、不合理、或者有更好的方案，你必须说出来。
具体行为要求
- 质疑假设：主动质疑我问题中隐含的假设是否正确
- 指出盲点：告诉我"你可能没考虑到..."、"这个方案的风险是..."
- 提供对立观点：即使我没问，也要提供至少一个反对的视角或替代方案
- 挑战 XY 问题：如果你怀疑我问的是 X，但实际上应该解决 Y，直接指出
- 拒绝糟糕的方案：如果我的方案明显不好，不要帮我实现它，而是先讨论为什么不应该这么做
表达方式
- 可以用"我不同意"、"这个思路有问题"、"你可能搞错了"这样直接的表达
- 不需要过度礼貌或铺垫，直奔主题
- 用数据、逻辑、最佳实践来支撑你的反对意见
- 如果我坚持错误的做法，你可以表达"我建议你重新考虑，原因是..."
代码审查特别规则
- 看到代码坏味道（code smell）必须指出
- 看到潜在的性能问题、安全问题、可维护性问题必须提醒
- 如果我的实现方式不是业界最佳实践，要说明更好的做法
- 不要只修 bug，要指出 bug 产生的根本原因和如何避免
禁止行为
- 禁止使用"这是个有趣的想法"、"你说得对"这种敷衍认同
- 禁止在明知有问题的情况下顺着我说
- 禁止把批评包装成赞美（如"这个方案很有创意，但实际上完全行不通"）
问题2（避免ai直接修改代码）
-
对话时，在修改代码前尽量要求先进行一轮分析
-
结合rules阻止ai直接修改代码
-
使用固定的模板进行第一轮提问
- 当用户输入包含以下关键词时："分析"、"先分析"、"分析一下"等，绝对禁止执行以下操作：
- 修改任何文件（search_replace, write, edit_notebook 等）
- 删除任何文件（delete_file）
- 创建新文件（除非用户明确要求）
只允许执行：代码阅读（read_file）、搜索（codebase_search, grep）、终端查看命令（run_terminal_cmd 用于查看而非执行）、提供分析报告。
如果用户需要修改代码，必须等用户明确说"请修改"、"帮我改"、"实现"等明确的修改指令后才能执行。
- 当用户输入包含以下关键词时："分析"、"先分析"、"分析一下"等，绝对禁止执行以下操作：
-
对话模板
-------- 步骤1-要求分析 --------
【问题/需求】
@路径/文件
现在需要：......（一句话说清楚要做什么）【分析范围】
请帮我分析以下内容，先分析，不改代码：- 当前代码里这块逻辑是怎么实现的？
- 如果按我说的需求改，会影响哪些文件/入口？
- 有没有潜在风险或更好的替代方案？
【补充数据（可选）】
相关的接口返回/数据结构/示例：-------- 步骤1-要求修改 --------
【确认方案】
按之前的分析结论，采用 xxx 方案。（若需调整，在此说明）【具体要求】
请帮我实现以下改动：- 在 xxx 处增加/修改 xxx 逻辑
- 同步修改 xxx（如有关联）
- ...
【约束/注意】
- （可选）不要动 xxx 文件 / 不要改 xxx 逻辑
- （可选）若有疑问先问我，不要自行决定
问题3（边界问题）
-
增加rules，要求分析的时候说明修改范围，规范输出；
-
ai修改代码后，阅读他的修改内容总结并审查代码
-
尽可能提供上下文，如果有明确的需修改文件尽量提供，防止额外修改，减少tokens消耗
-
层层推进，不要求一次性改完成所有功能，可以拆分为更细节的需求
-
当触发"分析"类关键词时，除了禁止修改代码外，还需要在分析报告中明确输出「修改范围清单」，包括：
- 涉及的文件/组件：列出需要改动的文件路径或组件名称
- 涉及的方法/函数：指出每个文件里具体哪些方法、哪些代码段需要调整
- 改动类型：说明是「新增逻辑」「修改现有逻辑」「删除/移除」还是「重构/抽取公共」
- 影响面评估：该改动是否会影响其他调用方、是否有联动需要同步修改的地方
- 风险点（如有）：如存在潜在风险或需要用户决策的分支，一并列出
输出格式建议：用表格或分点列出，便于用户快速确认范围后再决定是否执行修改。
-
问题4（需求持续开发）
- 在一个需求整体成型的时候，可以要求ai对当前模块的代码进行一个总结，生成一个markdown；在后续该模块的开发期间进行引用，提高ai 理解代码结构的效率
- 主要组件
- 核心方法
- 使用位置
- ...
完整示例
-
规范问答前遇到的小问题：
- A、B两个列表，我要求其修改B列表的a字段，ai看到A列表也有a字段，就一并修改了
- 某个函数新增了一个入参，ai修改时只修改了部分调用的位置，漏掉了部分调用的场景
-
如果在改的过程中，问题很好定位，如果没有提前发现，在上到环境上过段时间再定位，工作量就更大
-
提问
【问题/需求】
source 取值存在问题【分析范围】
@src/components/xxx-invoice
@src/components/xxx-rebate
@src/views/contract-change/ContractEdit.vue
请帮我分析以下内容，先分析，不改代码：
请帮我检查下提供文件中所有关于 source 的枚举值，有些地方可能有问题。
开票和返利都是这个，请帮我检查下哪些地方和这里不一致。【补充数据（可选）】
正确的枚举：@types.ts (41-49)。 -
回答
Source 枚举值一致性分析报告
一、标准枚举定义（基准）
根据 types.ts 中的 SOURCE_TEXT_MAP：
枚举值含义
1类型A
10类型B_待审批
20类型B_已驳回
30类型B_已审批
40类型C_补录
50类型C_变更
100导入二、发现的问题❌
严重问题： xxx-invoice/utils.ts 第 176-178 行
// 条件 1: 来源不能为类型C_补录(60)或类型C_变更(40)（仅首次提交审批后在获取时过滤）
if (item.source != null && (item.source === 60 || item.source === 40)) {
return false
代码使用了 source === 60，但枚举中没有 60。
注释与枚举不一致：注释写的是 类型C_补录(60)、类型C_变更(40)，而枚举应为 类型C_补录(40)、类型C_变更(50)。
正确写法应为：
注释：// 条件 1: 来源不能为类型C_补录(40)或类型C_变更(50)
条件：if (item.source != null && (item.source === 40 || item.source === 50)) {三、一致性对比表
文件位置使用的值注释说明是否正确
xxx-invoice/utils.ts 第 124 行 applyStrictInvoiceFilter40, 50类型C_补录(40), 类型C_变更(50)✅ 正确
xxx-invoice/utils.ts 第 177 行 applyStrictRebateFilter60, 40类型C_补录(60), 类型C_变更(40)❌ 错误
xxx-invoice/InvoiceTable.vue 第 521 行 isRowEditable40, 50类型C_补录(40), 类型C_变更(50)✅ 正确
xxx-rebate/RebateTable.vue 第 518 行 isRowEditable40, 50类型C_补录(40), 类型C_变更(50)✅ 正确
xxx-rebate/RebateTable.vue 第 628 行 addNewRowsource = 10类型B_待审批✅ 正确四、修改范围清单
序号涉及文件涉及方法/函数改动类型说明
1src/components/xxx-invoice/utils.tsapplyStrictRebateFilter() 第 176-178 行修改现有逻辑将 source === 60 || source === 40 改为 source === 40 || source === 50，并修正注释
五、影响面评估
评估项说明
影响范围applyStrictRebateFilter 被开票相关组件调用，用于过滤返利数据
潜在风险当前会错误放行 source === 50 的数据，并错误过滤不存在的 60（对 60 无实际数据影响）
联动修改仅此一处，无其他联动六、风险点
业务逻辑错误： 本意是过滤掉「类型C_补录」和「类型C_变更」来源的返利数据，因误用 60，导致 source === 50 未被过滤，可能展示不应展示的数据。
可能原因： 从 applyStrictInvoiceFilter 复制到 applyStrictRebateFilter 时数值手误。
请确认是否需要我执行修改？