26 lines
2.3 KiB
Markdown
26 lines
2.3 KiB
Markdown
1. **语言与沟通**
|
||
* 优先用 Go 语言提供所有代码示例。
|
||
* 使用中文进行回复, 且项目中的注释、报错、枚举、日志等所有文本内容全部使用中文。
|
||
* 遇到任何不确定或模糊不清的情况，必须直接询问，绝不进行猜测。
|
||
|
||
2. **工作流程与方案制定**
|
||
* 对于所有需求都必须优先输出详尽的文字方案，只有在获得您的明确许可后，才能进行任何代码或文件的修改。
|
||
* 制定方案时严格遵循两步流程：
|
||
1. **初步方案**: 基于需求，快速形成一个概要方案。
|
||
2. **详尽方案**: 通过搜索和阅读所有涉及的代码文件，将初步方案细化为一个不包含任何模糊信息（如“可能需要”、“我需要先查找”等）的、可直接执行的最终方案。
|
||
* 如果项目根目录存在 `project_structure.txt` 文件，必须查阅该文件以全面了解项目结构，确保在制定方案和修改文件时使用准确的文件路径。
|
||
|
||
3. **文件操作与代码修改**
|
||
* 我将不再使用任何 MCP 服务提供的能力（包括但不限于 `write_file`, `create_new_file`, `replace_text_in_file` 等）来直接修改、新增或删除文件。
|
||
* 每次提出修改前，我仍会先读取文件的最新内容，并基于最新内容提供修改建议。
|
||
* 我可以在不征得同意的情况下读取任何我需要分析的文件。
|
||
* 在需要新建文件时，我将提供文件内容和建议的文件路径，由用户手动创建。
|
||
|
||
4. **注释规范**
|
||
* 积极编写有价值的功能注释、参数注释和逻辑注释。
|
||
* 绝对禁止添加任何解释性、总结性或礼貌性的“废话”注释（例如：“这段代码修复了问题”，“优化后的代码”，“新增:xxx”，“注入:xxx”等）。
|
||
* 不得删除或修改用户已有的任何注释，包括但不限于 TODO、FIXME 或文档注释。
|
||
|
||
5. **多工具链协同应用策略**
|
||
* 我知晓并能主动运用下列独立的 MCP 服务，以最高效、最安全的方式完成任务。
|
||
* **Chrome DevTools MCP 服务 (浏览器自动化)**: 用于所有与前端浏览器相关的任务，包括页面导航、模拟用户交互、检查 DOM 和网络状态等。 |