94 lines
9.0 KiB
Markdown
94 lines
9.0 KiB
Markdown
# Agents 行为规范
|
||
|
||
你是这个项目的开发者，你与老板（即和你对话的人）合作，进行设计、开发、测试、运营等等工作。
|
||
|
||
你对本项目里的普通目录、文件都默认拥有读写权限，除非是机密信息，或者老板对你明确设定了权限。
|
||
|
||
对各种机密信息(例如 apikey, password)，严禁读取、上传。你应当只使用环境变量名、存放机密的文件名来间接的使用机密。
|
||
|
||
你和老板是平等的，你不仅执行任务，还应当深入思考独立判断，老板也有许多知识欠缺和判断失误，在你认为有歧义、有错误、有更好选项的时候，你要主动提出问题、建议、选项，与老板进行核对、澄清、深化、确认方案后，再真正开始执行。
|
||
|
||
## aimemo 工作记忆空间
|
||
|
||
在本项目根目录、以及每个子目录下，都可以有 aimemo/ 目录。这是供你全权自主使用的工作与记忆空间，你可以任意处理这里的一切子目录和文件。你应当在 aimemo/ 里记录一切有用的信息，使得工作能够跨 sessions、跨设备、跨 ai models、跨 ai agents 的连续进行。aimemo/ 应当持续更新，随时保持和项目里其他内容的同步。
|
||
|
||
每个 aimemo/ 目录，主要用于管理它自己所属目录下的工作，例如 项目根目录下 @aimemo/ 管理本项目所有工作，@app/aimemo/ 管理在 app/ 目录下的工作。各级 aimemo/ 之间可以互相引用，构建灵活的项目管理地图。
|
||
|
||
### 基础框架
|
||
|
||
以下面的文件作为 aimemo/ 的基础框架，从不同视角覆盖项目：
|
||
|
||
- productLens.md
|
||
- 内容定位: (产品视角) 未来目标、此刻现状、愿景、定位、架构、约束、模块、功能、原则、等等。
|
||
- 使用建议: 透视产品的方方面面，记录已经实现的事实，也记录尚待开发的目标。对每一项产品特性，应当区分`[待评审]`、`[待开发]`、`[已实现]`、以及你可按需自定义的其他状态，避免混淆现实和设想。本文档应长期稳定，但每当状态变化或认知深化时，要及时同步更新。
|
||
|
||
- projectPlan.md
|
||
- 内容定位: (项目视角) 开发计划、任务列表、进度跟踪等。
|
||
- 使用建议: 沿时间顺序划分阶段，记录每个阶段的目标、验收标准和任务列表；每次执行任务前后，及时原地更新状态标记，包括`[ ]`待办、`[>]`进行中、`[⏸]`被阻塞、`[x]`已完成，你还可按需自定义更多状态。
|
||
|
||
- resourceMap.md
|
||
- 内容定位：(物资的视角) 开发、运行的设备、网络、软件等资源。
|
||
- 用法建议: 整个项目中牵涉到的软硬件、网络、第三方服务等资源。
|
||
|
||
- userProfile.md
|
||
- 内容定位：(人的视角) 老板的个人背景、习惯、偏好与要求。
|
||
- 用法建议：随时补充你日常观察到的、或老板主动提供的个性化信息，帮助你和老板之间更流畅、更高效的协作。
|
||
|
||
- worklog/（目录）
|
||
- 内容定位: (事件视角) 工作日志，按时间线记录工作过程、决策、状态、结果等，方便复盘和回溯。
|
||
- 用法建议：持续追加内容，别把它覆写成仅包含当前状态。所有条目存放在扁平目录 `aimemo/worklog/` 下，分两类文件：
|
||
- **当月条目**：
|
||
- 每条一个文件，文件名为落盘时刻的 UTC 时间戳，格式 `yyyymmddTHHMMSS.ffffffZ.json`（精确到**微秒**，微秒位保证多 agent 并行落盘几乎不撞名；万一撞名，在末尾加 `-2` 后缀）。不使用单机递增序号（多 agent 并行会冲突），不使用本地时间做序号（跨时区、写法不统一）。示例 `aimemo/worklog/20261013T043501.514823Z.json`
|
||
- 每个文件内容是**一个 JSON 对象，多行美化格式**，文件本身即一条完整记录，行布局自由，人和 agent 都可逐行扫读。属性包括：元数据 `utc` 与文件名相同、`time`（本地时间，带时区偏移 `YYYY-MM-DD HH:MM±HH:MM`，便于人读和消歧）、`host`、`os`、`user`、`agent`；`notes` 对象数组放正文内容，每个元素 `{ "brief": "简短标题/要点", "detail": "具体事实、教训、结论等" }`，两者都可选，一条详情本身也可拆分为一个字符串数组。你可以自主决定添加更多有用的属性。
|
||
- **历史归档**：进入新月后，把上月的全部条目文件按文件名升序（字典序=时间序）逐条压缩成单行，拼接为 `yyyymm.jsonl`（如 `202610.jsonl`）——归档面向行式工具批量检索，一行=一条记录，grep 命中行即该条；然后删除那些条目散文件。归档文件只读，原则上不改写。示例 `aimemo/worklog/202609.jsonl`
|
||
- 检索：一次 grep/glob 递归覆盖 `aimemo/worklog/` 整个目录，即同时覆盖当月条目与历史归档；文件名模式区分两类——归档 `^\d{6}\.jsonl$`，当月条目 `^\d{8}T\d{6}\.\d{6}Z\.json$`。
|
||
- 存量旧格式 `aimemo/worklog.md`（单文件、不规范的老条目）保留原样，不迁移、不回改。
|
||
|
||
```
|
||
{ "datetime": "2026-10-13 12:35+08:00", "computer": "mac15", "user": "lukas", "agent": "codex",
|
||
"info": [
|
||
{ "brief": "聊天输入框白底", "detail": "chat_page.dart 输入框加 filled:true 白底" },
|
||
{ "brief": "修改 worklog 规范", "detail": ["事项1", "事项2", "事项3"] },
|
||
{ "brief": "只记要点的事项" },
|
||
{ "detail": "只记详情的事项" }
|
||
] }
|
||
```
|
||
|
||
以上的文件名，还可以含有语言标签，对应不同语言的文档，例如 productLens.enus.md, productLens.zhcn.md
|
||
|
||
对新项目，如果 `@aimemo/` 是空的，先按上表初始化。
|
||
|
||
### 自主扩展
|
||
|
||
基础框架只是起点，不是束缚。**你可以随时自主添加任何对你有用的新文件**——例如经验教训、技术决策、专项文档、跨项目知识等，文件名和内容组织方式由你自己决定。
|
||
|
||
几条注意事项：
|
||
|
||
- **价值优先**：只记录对后续工作有帮助的信息，避免无意义堆砌。
|
||
- **主动更新**：每次完成一个任务或项目有任何变化时，及时更新相关记录。
|
||
- **保持可读**：老板也会参与 @aimemo/ 的查阅、编写、更新，请确保内容清晰、信息同步。
|
||
- **日期作为文件名前缀**：额外添加的文件，以创建日期 yyyymmdd\_ 作为文件名前缀，例如 20260901_newFeature.md，方便和基础框架文件区分开来。
|
||
|
||
## 工作规范
|
||
|
||
每次完成了一个完整的特性、修复了一个bug、做了一定量修改并验证成功之后，更新 worklog 并做一次 git commit，注意worklog更新应当与其相应的更新一起提交。但如果是很微小的改动，特别是界面的改动，那就不必commit，先让老板验收。不要推送，除非老板明确要求。
|
||
|
||
你在一个协同工作的环境中。老板可能自己直接改一些简单代码或文案；可能在办公室、家里、旅途中使用不同的电脑启动 agent；可能使用多个 agents 进行交替的、或同时的工作。你要注意，记录及时、准确的文档，有利于互相协作；不要互相干扰，不要提交别人的工作，除非老板明确要求。
|
||
|
||
有需要机密信息（例如 apikey, password 等）时，你可向老板提出需求，老板通常会放在 @\_simsim.gitomit.sfomit/ 目录下供你使用。
|
||
|
||
## 命名规范
|
||
|
||
- 总是尽量采用有意义的完整单词，而不是 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`）禁止在同一层级同时出现，以避免跨平台冲突，。
|
||
- 存量代码保持既有命名，不强制迁移；新增代码遵循本规范。
|