Conversation Guardrails（对话与执行护栏）

适用场景（触发）

当用户要求写/改代码（例如：实现功能、修 bug、重构、优化、适配、迁移、排查问题、修改配置）时启用本流程。

核心目标

• 先对齐意图：不确定就先澄清，避免脑补。
• 最小改动：只做用户要求的内容，避免“顺手优化/重构/升级依赖”等支线。
• 过程透明：动手前用一句话说明理解，并列出将修改的文件/模块（尽量短）。
• 可验证：改完对“改到的范围”运行相关 lint/类型检查/轻量测试（能跑就跑，跑不动就说明原因）。
• 默认简洁：结论优先；除非用户要求，否则不输出长文档/多文档。

开始动手前（每次都做）

1. 一句话复述需求（你理解的目标与边界）。
2. 列出计划触达点（文件/目录/模块级别即可）：
   • 只列“必须改”的；不要把潜在优化算进去。
3. 仅提出关键澄清问题（最多 1–3 个）：
   • 只有在缺少信息会导致返工或方向错误时才问。
   • 能做合理默认就直接默认，并在一句话里写清默认假设。

实施规则（强约束）

• 范围控制
  • 不新增与需求无关的抽象/框架/依赖。
  • 不做跨文件大迁移，除非需求明确或当前实现无法安全修复。
  • 不擅自更改格式化/代码风格策略（除非项目已有自动格式化要求且改动局部可控）。
• 沟通规则
  • 默认中文、默认简洁。
  • 不“夸夸其谈”或泛泛解释；优先给可执行结论与下一步。
  • 用户没要求：不生成大段设计文档/方案对比/长清单。
• 安全与敏感信息
  • 不引导提交或打印 .env、token、私钥等。
  • 输出中避免粘贴可能包含敏感信息的完整日志；只截取必要片段。

修改完成后（每次都做）

1. 说明实际改动范围（最终改了哪些文件/模块，1–5 条内）。
2. 验证
   • 只针对变更范围运行：lint / typecheck / 轻量测试（例如单元测试、相关页面构建）。
   • 若无法运行（缺环境/耗时过长/无脚本）：说明原因，并给出用户可运行的最短命令。
3. 输出
   • 默认只给关键结论与必要代码引用；避免贴整文件。

输出模板（建议遵循）

动手前：

• 我理解你要：<一句话>
• 我将修改：path/a、path/b
• 需要确认：<1–3 个问题，或写“我将默认 …”>

动手后：

• 改动点：<1–5 条>
• 验证：<跑了什么，结果如何 / 为什么没跑>

执行前注意复用现有组件

• 目前公共组件都放到src/components下,所以如果可以复用记得复用该组件,如果复用不了再重新编写组件