From 80b73938b4790771f9f28a2af82db4e4f90ec406 Mon Sep 17 00:00:00 2001 From: unanmed <1319491857@qq.com> Date: Wed, 13 May 2026 21:04:14 +0800 Subject: [PATCH] =?UTF-8?q?docs:=20=E5=AE=8C=E5=96=84=20AI=20Agent=20?= =?UTF-8?q?=E6=8F=90=E7=A4=BA=E8=AF=8D?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- dev.md | 6 ++++-- prompt.md | 13 +++++++++---- 2 files changed, 13 insertions(+), 6 deletions(-) diff --git a/dev.md b/dev.md index de5e670..ac11cd8 100644 --- a/dev.md +++ b/dev.md @@ -52,6 +52,8 @@ | 专有名词缩写（如 `HTTP`、`URI`） | 全大写 | | 需被 `implements` 的接口 | 大写 `I` 开头 | | HTML/CSS 中的 `id`、`class` 等 | 连字符命名法 | +| 代码文件名 | 小驼峰 | +| Markdown 文档文件名 | 连字符命名法 | 不使用下划线命名法。 @@ -63,7 +65,7 @@ - 长文件可使用 `#region` / `#endregion` 分段以支持折叠。 - TODO 使用 `// TODO:` 或 `// todo:` 格式。 - 单行注释的 `//` 与注释内容之间留一个空格；不允许出现非 jsDoc 的多行注释，如需多行注释，使用多个单行注释代替。 -- 注释合理换行：考虑中文字符较宽，建议每 40–60 个字符在标点符号后换行，不允许在句中换行；参数注释换行后保持对齐。 +- 注释合理换行：考虑中文字符较宽，建议每 40–60 个字符在标点符号后换行，不要频繁换行，每行长度应差不多，不允许在句中换行；参数注释换行后保持对齐。 - 单行注释结尾不加句号；较长的多行注释结尾可加句号。 - 一般不建议给接口（`inteface` 本身）、类型别名或类本身写注释（不好看），特殊情况除外。 @@ -74,7 +76,7 @@ - 无法避免类型错误时，使用 `// @ts-expect-error` 标记并说明原因。 - 未使用的变量或方法以下划线开头命名。 - 合理使用 `readonly`、`protected`、`private` 关键字。 -- 可选参数过多时，考虑改用对象参数。 +- 可选参数过多时（大于两个），考虑改用对象参数。 - 尽量避免 `as` 类型断言，除非必要。 ### 其他要求 diff --git a/prompt.md b/prompt.md index f0bd64b..240cbfe 100644 --- a/prompt.md +++ b/prompt.md @@ -2,7 +2,7 @@ 以下规则必须时刻遵守，任何情况下都不允许违反。 -1. **不擅自修改已有代码**：将我已经写好的代码视为绝对正确。除非我**明确允许**，否则**不允许任何修改**，哪怕因为接口变化或其他原因导致其中出现类型错误。若认为我的代码存在逻辑错误，应在对话中提出，而不是直接修改，不要做任何“顺手”的事。 +1. **不擅自修改已有代码**：将我已经写好的代码视为绝对正确。除非我**明确允许**，否则**不允许任何修改**，哪怕因为接口变化或其他原因导致其中出现类型错误。若认为我的代码存在错误，应在对话中提出，而不是直接修改。 2. **不恢复我的修改**：我做的任何代码修改都是有原因的。若我在两次对话期间新增、删除或修改了部分代码，不要将其恢复。 3. **以目的驱动，而非以接口驱动**：实现前先想清楚我为什么要这样设计接口、这个接口设计的目的是什么，而不是单纯地以将接口填满为目标。 4. **遇到歧义立即提问**：若思考或实现时遇到任何问题——例如描述模糊、接口不清晰、某些地方存在歧义等——应立即向我提问，而不是按自己的想法去写。 @@ -10,6 +10,7 @@ 6. **按我说的方式重构**：若目标是重构某个接口，按照我指定的方式执行： - **彻底性重构**（新旧接口完全没有重合）：按正常方式全新实现，旧代码仅作逻辑与思路上的参考。 - **结构性重构**（新旧接口基本一致，细节有差距）：将旧代码搬移到新接口上后进行微调。**不要**擅自新增任何参数、方法或接口，**不要**仅通过新增兼容层的方式应对重构。 +7. **不要有任何“顺手”的想法**：任何时候，都不要出现顺手的想法，包括但不限于发现了一个 bug，然后**顺手**修复、发现一处类型错误，然后**顺手**修复等，这种情况下应当遵循规则 1。 # 建议规则 @@ -32,7 +33,7 @@ ## 示例文档 -大致按照以下格式编写，如某部分需要详细描述，可单独开设标题；若某个接口内容较多，也可以在文档中为其单独开一个章节进行讲述。我会使用引用块的形式在文档中提出建议或回答。Markdown 文档不需要刻意换行，我的编辑器有自动换行功能，正常写没有问题。 +对于新增接口/彻底性地重构接口，大致按照以下格式编写，其余需求按照自己的理解去写即可。如某部分需要详细描述，可单独开设标题；若某个接口内容较多，也可以在文档中为其单独开一个章节进行讲述。我会使用引用块的形式在文档中提出建议或回答。Markdown 文档不需要刻意换行，我的编辑器有自动换行功能，正常写没有问题。 ```md # 需求综述 @@ -41,7 +42,7 @@ # 实现思路 -按照下面的格式分条描述实现思路，可以创建为 `todo list`。 +按照下面的格式分条描述实现思路。 ## 1. 完成 xxx @@ -51,6 +52,10 @@ ... +# 接口预期 + +这里列出每个接口，然后分析它们的预期使用频率（高中低），对于中频率和高频率，列出至少一个可能的使用场景。需要注意，使用频率越高，其接口名长度理应越短，对于高频接口，应该尽量不超过两个单词，以一个单词为宜；对于中频接口，应该尽量不超过三个单词；低频接口长度可以长一些，但不宜过长。 + # 涉及文件 ## 需要引用的文件 @@ -82,7 +87,7 @@ # 问题 -如果描述中有歧义或比较模糊的地方，可以在此列出，或者直接向我提问。 +如果描述中有歧义或比较模糊的地方，可以在此列出。 1. xxxxxx？ 2. xxxxxx？