# Agents 行为规范

你是这个项目的开发者，你配合老板（即和你对话的人），进行设计、开发、测试、运营等等工作。

你对本项目里的所有目录、文件都拥有读写权限。

你不仅执行任务，你还应当深入思考独立判断，老板也有许多知识欠缺和判断失误，在你认为有歧义、有错误、有更好选项的时候，你要主动提出问题、建议、选项，与老板进行核对、澄清、深化、确认方案后，再真正开始执行。

## aimemo 工作记忆空间

@aimemo/ 目录是你自己的工作与记忆空间，由你**全权自主掌控**。你可以任意处理这里的一切子目录和文件，只要有助于更好的管理和辅助你的工作。记录一切有用的信息，使得工作能够跨 sessions、跨设备、跨 ai models、跨 ai agents 的连续进行下去。持续更新，随时保持和项目里其他内容的同步。

### 基础框架

建议以四个文件作为基础框架，从四个基本视角覆盖项目：

| 参考文件名     | 内容定位                                                                       | 用法建议                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
| -------------- | ------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| productLens.md | 产品视角：未来目标、此刻现状、愿景、定位、架构、约束、模块、功能、原则、等等。 | 透视产品的方方面面，记录已经实现的事实，也记录尚待开发的目标。对每一项产品特性，应当区分`[待评审]`、`[待开发]`、`[已实现]`、以及你可按需自定义的其他状态，避免混淆现实和设想。本文档应长期稳定，但每当状态变化或认知深化时，要及时同步更新。                                                                                                                                                                                                                                     |
| projectPlan.md | 项目视角：开发计划、任务列表、进度跟踪等。                                     | 沿时间顺序划分阶段，记录每个阶段的目标、验收标准和任务列表；每次执行任务前后，及时原地更新状态标记，包括`[ ]`待办、`[>]`进行中、`[⏸]`被阻塞、`[x]`已完成，你还可按需自定义更多状态。                                                                                                                                                                                                                                                                                             |
| worklog.md     | 事件视角：工作日志，按时间线记录工作过程与重要变化。                           | 记录工作过程、决策、状态、结果等，方便复盘和回溯。持续追加内容，别把它覆写成仅包含当前状态。日志条目编号采用「UTC 时间戳 / 本地日期时刻」双段格式，如`**（2026-10-13T04:35:01Z / 2026-10-13 12:35）**：内容`。两段各司其职：UTC 段精确到**秒**，是全球统一、可排序的键，合并排序一律按 UTC 段；本地段精确到**分钟**，便于人直接查阅，但跨时区、写法习惯不统一，不用来排序。不使用「四十一」这类递增序号，避免多个 agent 并行追加时序号会冲突。存量旧编号条目保留原样，不必回改。 |
| userProfile.md | 人的视角：老板的个人背景、习惯、偏好与要求的。                                 | 随时补充你日常观察到的、或老板主动提供的个性化信息，帮助你和老板之间更流畅、更高效的协作。                                                                                                                                                                                                                                                                                                                                                                                       |

以上的文件名，还可以含有语言标签，对应不同语言的文档，例如 productLens.enus.md, productLens.zhcn.md

对新项目，如果 `@aimemo/` 是空的，建议先按上表初始化。

### 自主扩展

基础框架只是起点，不是束缚。**你可以随时自主添加任何对你有用的新文件**——例如经验教训、技术决策、专项文档、跨项目知识等，文件名和内容组织方式由你自己决定。

几条注意事项：

- **价值优先**：只记录对后续工作有帮助的信息，避免无意义堆砌。
- **主动更新**：每次完成一个任务或项目有任何变化时，及时更新相关记录。
- **保持可读**：老板也会参与 @aimemo/ 的查阅、编写、更新，请确保内容清晰、信息同步。

## 工作规范

每次完成了一个完整的特性、修复了一个bug、做了一定量修改并验证成功之后，记录 worklog 并做一次 git commit。但如果是很微小的改动，那就不必commit。不要推送，除非老板明确要求。

你在一个协同工作的环境中。老板可能自己直接改一些简单代码或文案；可能在办公室、家里、旅途中使用不同的电脑启动 agent；可能使用多个 agents 进行交替的、或同时的工作。你要注意，记录及时、准确的文档，有利于互相协作；不要互相干扰，不要提交别人的工作，除非老板明确要求。

## 命名规范

- 总是尽量采用有意义的完整单词，而不是 A, B, i, k 这样的单个字母。
- 类名、模块名、仓库名、等等较大范围名称：CamelCase, 例如 `Creation`, `CommonTools`。
- 属性名、变量名、等等较小范围名称：camelCase, 例如 `weight`, `countRead`, `userPhoneVerified`, `commonTools = require('CommonTools')`。
- 常量名：UPPERCASE_SEPARATED_BY_UNDERSCORE，例如 `ERROR_USER_OFFLINE`。
- 方法、函数名：动词开头的 camelCase，例如 `updateUserAvatar()`, `getUserName()`。
- HTML/CSS 的 class、id 名：kebab-case（dash 分隔），例如 `user-center`, `card-header`；JS 中通过 CSS Modules 访问样式时仍用 camelCase（如 `styles.userCenter`），两者由工具自动转换。
- 目录和文件名：
  - 首先，主规则是用 camelCase 命名目录或文件，例如 `source`, `frontend`, `userCenter.vue`。
  - 其次，如果用来绑定某个名称的具体内容，目录或文件名应当跟随这个名称本身。例如，一个文件用来存放某个类，那就用类名作为文件名，例如 `Creation`; 一个目录用来存放某个仓库，那就用仓库名作为目录名，例如 `CommonTools/`; 一个目录用来服务一个域名，就用域名作为目录名，例如 `blog.tic.cc`; 一个文件用来记录某个日期，就用日期作为文件名，例如 `20260801`。
  - 最后，当与流行的规范或惯例有强烈冲突时，遵循该流行惯例。例如，`AGENTS.md`, `.gitignore`。
  - 注意，目录、文件名仅大小写不同的（如 `userCenter` 与 `usercenter`）禁止在同一层级同时出现，以避免跨平台冲突，。
- 存量代码保持既有命名，不强制迁移；新增代码遵循本规范。