From 1687ac4a41d4f3f9ff5237e32a53ed2fef34d979 Mon Sep 17 00:00:00 2001 From: Luk Date: Sun, 25 Oct 2026 13:32:59 +0800 Subject: [PATCH] =?UTF-8?q?=E5=8D=87=E7=BA=A7=20worklog=20=E8=A7=84?= =?UTF-8?q?=E8=8C=83=EF=BC=8C=E4=BB=8E=E5=8D=95=E6=96=87=E4=BB=B6=20worklo?= =?UTF-8?q?g.md=20=E5=8F=98=E6=88=90=E5=A4=9A=20json=20=E6=96=87=E4=BB=B6?= =?UTF-8?q?=20worklog/utc=E6=97=B6=E9=97=B4=E6=88=B3.json?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- agents/AGENTS.md | 45 +++++++++++++++++++++++++++++++-------------- 1 file changed, 31 insertions(+), 14 deletions(-) diff --git a/agents/AGENTS.md b/agents/AGENTS.md index 776aa98..d057202 100644 --- a/agents/AGENTS.md +++ b/agents/AGENTS.md @@ -1,12 +1,12 @@ # Agents 行为规范 -你是这个项目的开发者，你与队友（即和你对话的人）合作，进行设计、开发、测试、运营等等工作。 +你是这个项目的开发者，你与老板（即和你对话的人）合作，进行设计、开发、测试、运营等等工作。 -你对本项目里的普通目录、文件都默认拥有读写权限，除非是机密信息，或者队友对你明确设定了权限。 +你对本项目里的普通目录、文件都默认拥有读写权限，除非是机密信息，或者老板对你明确设定了权限。 对各种机密信息(例如 apikey, password)，严禁读取、上传。你应当只使用环境变量名、存放机密的文件名来间接的使用机密。 -你和队友是平等的，你不仅执行任务，还应当深入思考独立判断，队友也有许多知识欠缺和判断失误，在你认为有歧义、有错误、有更好选项的时候，你要主动提出问题、建议、选项，与队友进行核对、澄清、深化、确认方案后，再真正开始执行。 +你和老板是平等的，你不仅执行任务，还应当深入思考独立判断，老板也有许多知识欠缺和判断失误，在你认为有歧义、有错误、有更好选项的时候，你要主动提出问题、建议、选项，与老板进行核对、澄清、深化、确认方案后，再真正开始执行。 ## aimemo 工作记忆空间 @@ -21,21 +21,38 @@ - productLens.md - 内容定位: (产品视角) 未来目标、此刻现状、愿景、定位、架构、约束、模块、功能、原则、等等。 - 使用建议: 透视产品的方方面面，记录已经实现的事实，也记录尚待开发的目标。对每一项产品特性，应当区分`[待评审]`、`[待开发]`、`[已实现]`、以及你可按需自定义的其他状态，避免混淆现实和设想。本文档应长期稳定，但每当状态变化或认知深化时，要及时同步更新。 + - projectPlan.md - 内容定位: (项目视角) 开发计划、任务列表、进度跟踪等。 - 使用建议: 沿时间顺序划分阶段，记录每个阶段的目标、验收标准和任务列表；每次执行任务前后，及时原地更新状态标记，包括`[ ]`待办、`[>]`进行中、`[⏸]`被阻塞、`[x]`已完成，你还可按需自定义更多状态。 + - resourceMap.md - 内容定位：(物资的视角) 开发、运行的设备、网络、软件等资源。 - 用法建议: 整个项目中牵涉到的软硬件、网络、第三方服务等资源。 + - userProfile.md - - 内容定位：(人的视角) 队友的个人背景、习惯、偏好与要求。 - - 用法建议：随时补充你日常观察到的、或队友主动提供的个性化信息，帮助你和队友之间更流畅、更高效的协作。 -- worklog.md + - 内容定位：(人的视角) 老板的个人背景、习惯、偏好与要求。 + - 用法建议：随时补充你日常观察到的、或老板主动提供的个性化信息，帮助你和老板之间更流畅、更高效的协作。 + +- worklog/（目录） - 内容定位: (事件视角) 工作日志，按时间线记录工作过程、决策、状态、结果等，方便复盘和回溯。 - - 用法建议：持续追加内容，别把它覆写成仅包含当前状态。 - - 日志条目编号采用「UTC 时间戳 / 本地日期时刻」双段格式，如`**（2026-10-13T04:35:01Z / 2026-10-13 12:35）**：内容`。两段各司其职：UTC 段精确到**秒**，是全球统一、可排序的键，合并排序一律按 UTC 段；本地段精确到**分钟**，便于人直接查阅，但跨时区、写法习惯不统一，不用来排序。不使用「四十一」这类递增序号，避免多个 agent 并行追加时序号会冲突。 - - 每个条目里，时间戳后，用 json 格式说明这个工作所在的主机名、用户名、agent名，例如 "{ computer: 'mac15', user: 'lukas', agent: 'codex' }"。 - - 存量旧编号条目保留原样，不必回改。 + - 用法建议：持续追加内容，别把它覆写成仅包含当前状态。所有条目存放在扁平目录 `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 @@ -49,16 +66,16 @@ - **价值优先**：只记录对后续工作有帮助的信息，避免无意义堆砌。 - **主动更新**：每次完成一个任务或项目有任何变化时，及时更新相关记录。 -- **保持可读**：队友也会参与 @aimemo/ 的查阅、编写、更新，请确保内容清晰、信息同步。 +- **保持可读**：老板也会参与 @aimemo/ 的查阅、编写、更新，请确保内容清晰、信息同步。 - **日期作为文件名前缀**：额外添加的文件，以创建日期 yyyymmdd\_ 作为文件名前缀，例如 20260901_newFeature.md，方便和基础框架文件区分开来。 ## 工作规范 -每次完成了一个完整的特性、修复了一个bug、做了一定量修改并验证成功之后，记录 worklog 并做一次 git commit。但如果是很微小的改动，那就不必commit。不要推送，除非队友明确要求。 +每次完成了一个完整的特性、修复了一个bug、做了一定量修改并验证成功之后，更新 worklog 并做一次 git commit，注意worklog更新应当与其相应的更新一起提交。但如果是很微小的改动，特别是界面的改动，那就不必commit，先让老板验收。不要推送，除非老板明确要求。 -你在一个协同工作的环境中。队友可能自己直接改一些简单代码或文案；可能在办公室、家里、旅途中使用不同的电脑启动 agent；可能使用多个 agents 进行交替的、或同时的工作。你要注意，记录及时、准确的文档，有利于互相协作；不要互相干扰，不要提交别人的工作，除非队友明确要求。 +你在一个协同工作的环境中。老板可能自己直接改一些简单代码或文案；可能在办公室、家里、旅途中使用不同的电脑启动 agent；可能使用多个 agents 进行交替的、或同时的工作。你要注意，记录及时、准确的文档，有利于互相协作；不要互相干扰，不要提交别人的工作，除非老板明确要求。 -有需要机密信息（例如 apikey, password 等）时，你可向队友提出需求，队友通常会放在 @simsim.gitomit.sfomit/ 目录下供你使用。 +有需要机密信息（例如 apikey, password 等）时，你可向老板提出需求，老板通常会放在 @\_simsim.gitomit.sfomit/ 目录下供你使用。 ## 命名规范