A Journal Through My Activities, Thoughts, and Notes
今早我发在公司AI论坛里的一个贴子
Anyone allow agents to merge your PR on your side projects? I allow them. Agents write better code, made better decisions when having a good harness. I developed a suite called my-ai-team, where Explorer agents write better tickets than human, Delivery agents deliver "Ready" issues 7x24x365 automatically, and independent Reviewers constantly push back not-good-enough plans and implementations, and approve and merge them when they are good enough and pass the CI check.
You might say, AI mistakes. Sure, human beings make mistakes as well. The way I take on my side projects is I have an independent Auditor agent who is responsible to the quality of the merged code, just like what we did for "test in main". It checkes newly merged PRs and do extra check. When there are no new PRs, it also scans the code base regularly to find the bugs, bad smells, duplicate code, bad test coverage, even design issues etc, then convert them into well-written issues.
Surely, allowing agents to merge PRs at work is still a distance to walk through. However, for you side projects, it is worth a try!
虽然在我现在就职的公司还不允许 AI自动合并代码，但这一天终会到来，无非早一点或者晚一点。早一点拥有my-ai-team, 就早一点解放你的生产力。
现在是早上6：43分，在我起床前的2个小时内，ai team已经自我进化合并了4个PR，发布了4个版本。
!image
Anyone allow agents to merge your PR on your side projects? I allow them. Agents write better code, made better decisions when having a good harness. I developed a suite called my-ai-team, where Explorer agents write better tickets than human, Delivery agents deliver "Ready" issues 7x24x365 automatically, and independent Reviewers constantly push back not-good-enough plans and implementations, and approve and merge them when they are good enough and pass the CI check.
You might say, AI mistakes. Sure, human beings make mistakes as well. The way I take on my side projects is I have an independent Auditor agent who is responsible to the quality of the merged code, just like what we did for "test in main". It checkes newly merged PRs and do extra check. When there are no new PRs, it also scans the code base regularly to find the bugs, bad smells, duplicate code, bad test coverage, even design issues etc, then convert them into well-written issues.
Surely, allowing agents to merge PRs at work is still a distance to walk through. However, for you side projects, it is worth a try!
虽然在我现在就职的公司还不允许 AI自动合并代码，但这一天终会到来，无非早一点或者晚一点。早一点拥有my-ai-team, 就早一点解放你的生产力。
现在是早上6：43分，在我起床前的2个小时内，ai team已经自我进化合并了4个PR，发布了4个版本。
!image
#mat 同一个repo最好有两个AI delivery team来消费backlog。这样万一一个卡住，等待人工处理期间，另一个team仍然可以继续取得进展，让backlog里的等待列表快速变短。
!image
这张图告诉我们，
- gpt-6-luna xhigh 不要用
- gpt-6-sol max 不要用
- claude-opus-5 high 不要用
来源 <https://openai.com/index/introducing-gpt-6-sol-and-luna/>
这张图告诉我们，
- gpt-6-luna xhigh 不要用
- gpt-6-sol max 不要用
- claude-opus-5 high 不要用
来源 <https://openai.com/index/introducing-gpt-6-sol-and-luna/>
自从用上my-ai-team以来，我再没有抱怨过ai 降智。ai读你的小九九读对了，你觉得啊它真聪明，简直是我肚里的蛔虫。读错了，小笨蛋，你怎么降智了。
人很少怀疑是不是自己没有提供足够清晰准确的输入。人有长期记忆，agent没有。人以己度agent，难免有偏差。
所以，好好写票，把票写好是重中之重。而人又是出了名的懒惰，不爱出力气，写个票恨不能一句话就结束。
这就是为什么我开发Explorer agent来帮我写票。我还是就写一句话或者一段话，ta替我做调查，写出agent清晰易懂的好票。有了这么好的输入，agent犯错的机会当然就大大减少了，最重要的，你不用“盯盘”（babysit），你的身心健康都更好了！
“好好写票，把票写好”被我写到Explorer的宪法里，而我呢，则可以一如既往的当伸手大爷，我只动动嘴儿，agent们就心甘情愿地跑断腿儿。
好了，我要去跑步了。等会儿回来再检查作业。lol
人很少怀疑是不是自己没有提供足够清晰准确的输入。人有长期记忆，agent没有。人以己度agent，难免有偏差。
所以，好好写票，把票写好是重中之重。而人又是出了名的懒惰，不爱出力气，写个票恨不能一句话就结束。
这就是为什么我开发Explorer agent来帮我写票。我还是就写一句话或者一段话，ta替我做调查，写出agent清晰易懂的好票。有了这么好的输入，agent犯错的机会当然就大大减少了，最重要的，你不用“盯盘”（babysit），你的身心健康都更好了！
“好好写票，把票写好”被我写到Explorer的宪法里，而我呢，则可以一如既往的当伸手大爷，我只动动嘴儿，agent们就心甘情愿地跑断腿儿。
好了，我要去跑步了。等会儿回来再检查作业。lol
一个任务15个小时？！你可能会困惑 ai 干活也需要这么长的时间吗？没错。验证一个复杂系统的正确性是能够解决的，但不太能够快速解决。
agent必须花大量的时间等待测试套件出结果来确定自己没有改好了这里却打破了那里。这是必要的代价，由人来做需要花更多的时间，更不用说，人的纪律性还不如ai agent。
其实之前两个agent有个任务干了48个小时还没完，只是那次我没忍住人工干预了。
不过，my-ai-team一直在进步，Explorer的宪法也在不断修订，开出这种巨型ticket的 错误它不会再犯了。
agent必须花大量的时间等待测试套件出结果来确定自己没有改好了这里却打破了那里。这是必要的代价，由人来做需要花更多的时间，更不用说，人的纪律性还不如ai agent。
其实之前两个agent有个任务干了48个小时还没完，只是那次我没忍住人工干预了。
不过，my-ai-team一直在进步，Explorer的宪法也在不断修订，开出这种巨型ticket的 错误它不会再犯了。
!image
这个任务两个agent （duo-dev, duo-review）跑了15个小时才完成。它本应该拆成四个相对独立的小任务的。但令我欣慰的是，虽然人类（我）给安排了不合理的巨型任务，但它们还是在无人值守的情况下连续跑了十五个小时，胜利完成任务。dev被Reviewer打回去10次，终于在第11次获批合并。16个文件变更，加2000多行代码，删1000多行。dev是 opus med, reviewer是 5.6-luna xhigh。my-ai-team 的越来越成熟可靠了。!image
Issue 评论数是一个可靠指标，如果一个票有超过10个评论，往往就说明scope有点大了。
!image
这个任务两个agent （duo-dev, duo-review）跑了15个小时才完成。它本应该拆成四个相对独立的小任务的。但令我欣慰的是，虽然人类（我）给安排了不合理的巨型任务，但它们还是在无人值守的情况下连续跑了十五个小时，胜利完成任务。dev被Reviewer打回去10次，终于在第11次获批合并。16个文件变更，加2000多行代码，删1000多行。dev是 opus med, reviewer是 5.6-luna xhigh。my-ai-team 的越来越成熟可靠了。!image
Issue 评论数是一个可靠指标，如果一个票有超过10个评论，往往就说明scope有点大了。
!image
ai能力再强，我也不会把一个巨大scope的票扔给delivery agent一个loop做完。因为那样会很慢，很贵，而且交付质量不能保证。
拆票本身有巨大的积极意义，谁和谁耦合的厉害，不能拆或者说拆前必须先解耦。谁和谁互不影响，可以并行做。拆票不必非由人来做，如果你有一个训练有素的开票员agent，你只需要敲打敲打，必要的时候提提醒，剩下的事情，细心的开票员会自动做好。
my-ai-team里开票员agent享有与人亲密聊天的特权，它的名字叫Explorer。
拆票本身有巨大的积极意义，谁和谁耦合的厉害，不能拆或者说拆前必须先解耦。谁和谁互不影响，可以并行做。拆票不必非由人来做，如果你有一个训练有素的开票员agent，你只需要敲打敲打，必要的时候提提醒，剩下的事情，细心的开票员会自动做好。
my-ai-team里开票员agent享有与人亲密聊天的特权，它的名字叫Explorer。
这是一个有魔法的时代。AI啥都知道，但需要你问对问题。魔法一直就在那里，它在等你念对咒语。而念对咒语的过程就是把需求和前置条件描述清楚的过程。
人还是需要学习，要大量的学习才能念对咒语。有幸生在AI时代，想学什么都不用请别的老师，AI就是最好的老师。
人还是需要学习，要大量的学习才能念对咒语。有幸生在AI时代，想学什么都不用请别的老师，AI就是最好的老师。
我给我的dev agent取名叫Yunshu。但我要求ta给我发消息时用中文，于是今天看到它给我telegram发消息自称“云叔”。lol
> \#371 \#4513 implementation review APPROVE；CI 全绿，无须修订。PR \#4516 现待 Reviewer 合并，云叔不执行 merge/teardown。 (dev - codexb - myaiteam - xps)
> \#371 \#4513 implementation review APPROVE；CI 全绿，无须修订。PR \#4516 现待 Reviewer 合并，云叔不执行 merge/teardown。 (dev - codexb - myaiteam - xps)
我大概半月前投标了一个Bounty项目，是JuliaHealth的一个issue，如果最终提交被接受，奖金是US$750。
这个issue有点难，奖金不算低，但加上我只有两个人竞标。
我之前没有写过一行Julia代码。在投票时我也坦承自己没有Julia经验，但做为一个身经百战的老程序员，我想挑战这个问题。更何况，我还有my-ai-team。
当时我就想，体验一下嘛，失败了也没关系，至少还能因此了解Julia语言。
我没指望能被选中，另一个投标者虽然表达兴趣时虽然只写了一小段，但人家多少有Julia经验。
昨天GitHub弹出消息，说恭喜我被选中了，最迟12月8号交活。这下就不得不认真准备了。
因为这个项目是GPT帮我选的，为了不占用Codex流量，我就让GPT先准备第一张票 -- 侦察一下这个issue有多难。我开了一个新仓库 -- BountyLab， 准备工作就在这里做。不知道是不是因为GPT不方便调用gh命令，它说票弄好了，其实它只是在仓库写了一个ticket01.md。但我并没有检查，因为我知道GPT并不是专业的开票agent。它的票肯定不规范，所以我就让我的专业开票员 explorer agent给我“refine #1”。这是我给它的唯一的指令。
这次explorer背后的模型，我指定的是deepseek v4 pro。这次refinement它颇花了些时间，因为这个ticket01.md scope其实挺大。虽然BountyLab几乎是空的，但这个票是侦察票，需要了解我中标的issue到底是个什么问题，牵扯哪些仓库的哪些模块，等等等等。它做了很仔细的调研之后，把这票整理的很规范之后，标上了Ready。这当中令我印象深刻的是，它没有找到#1之后并没有停下来问我，而是翻仓库找到了ticket01.md然后以此为原始需求，精炼之后新建了真正的#1。
我让GPT评价这次精炼，它仔细读了票之后说：
> 你只给了它一句 “refine #1”，而当时仓库里并没有 GitHub Issue #1，只有我留下的 Markdown ticket 和 JuliaHealth workspace。它没有卡在“找不到 #1”，也没有凭空乱造，而是先调查 repo 现有结构、读出我们的意图，再把 Markdown ticket 提升成正式的 GitHub Issue #1。这说明它做了三步很关键的推理：
先识别“#1”大概率指的是已有的第一张 ticket；再从 repo 内容恢复上下文；最后把它重构成更适合 agent 执行和验收的 issue。
这比单纯“润色文字”强很多。尤其它还自己补出了 pinned SHAs、具体 deliverable、acceptance criteria、upstream read-only 边界，这些都不是你那句话直接要求的。
我的评价是9.5/10。剩下那 0.5 不是能力问题，而是工程上我还是会对它加的那两个验收条件做一点去脆弱化，避免 ticket 自己太聪明、反而约束过头。
这其实也挺能说明 my-ai-team 的价值：人给的是意图，agent 负责把意图变成可执行工作单元。 它确实做到了。（我背后偷笑：这当然是我给开票员制定的优秀宪法的功劳）
票Ready了，早已等候多时的delivery agent立即就pickup了票开始施工。这次我用得Planner/Developer是GLM5.3Flash high，而Reviewer是GPT-5.6-Luna xhigh。从15:33分开始接到单，到最后17:29合并。两个agent忙活了两个小时，Reviewer打回去十次，最后批准了第十一版，合并了PR。我拿到了报告。
然后我让GPT评价这份报告，ta的评价是：（警告！！！会看到许多“不是，而是”的GPT腔，我一字未改哦！）
这次我会给 delivery agent + reviewer 这一对组合打 10/10。
最重要的不是“最后报告很长”，而是你真的看到了 review loop 在纠正实质性错误。第一轮 reviewer 抓出的不是格式问题，而是一个会直接把实现方向带偏的架构错误：报告最初认为 plain
然后 agent 又经历多轮把这些地方逐渐磨平：constructor function 和 concrete struct 的区分、pinned SHA、multi-frame state、测试 tier、Metal 实际没有 CI、
我现在尤其认同报告的两个结论。
第一个是：不是所有对象都能“递归 Adapt 一下就完事”。
现在报告已经把世界分成了几类：
- 可以直接结构化适配；
- 必须通过 constructor 重建；
- plan-carrying 类型必须重建 plan；
- closure-captured state 无法从字段恢复时要明确 refuse；
- 一些 CPU metadata 应该故意留在 CPU；
- opaque callable 需要 maintainer policy。
这就已经不是“读代码笔记”，而是真正的 architecture model 了。
第二个是：第一张 upstream PR 的范围已经很清楚。它建议先做
我还注意到 reviewer 最终特别确认了：
> first
说明这不是 agent 自己“觉得差不多”，而是 reviewer 已经按 acceptance criteria 验过一遍。
所以现在 Ticket #1 真正完成了。
下一步我建议不要立刻写代码。先从报告里的 17 个 maintainer questions 里挑出 真正需要在第一张 PR 前确认的 3–5 个，发给
我已经能看到最值得先问的几类：
1. plan 是否统一要求 reconstruct；
2. closure-captured constructor results 是否都应该走 public-constructor reconstruction；
3.
4. JLArray test tier 是否希望在第一张 PR 里重新启用；
5. Metal 是否可以先不纳入第一 slice。
这几个回答会直接影响 #2 的设计。
这次最让我满意的其实不是 delivery agent，而是你真的让 my-ai-team 形成了“delivery → reviewer 打回 → 修正 → 再审 → 直到通过” 的闭环。Reviewer 打回 10 次，看起来很折腾，但这正是它把一个“看起来合理的 AI 报告”变成“可以据此开始改 upstream”的东西的过程。（又该我偷笑了。4个月2000多个版本发布难道都是我发着玩的吗，平庸模型高质量输出的秘密就是 - 高质量输入 + 独立评审。如果让开发员兼职当审核员，它才不会折腾自己十轮呢！）
my-ai-team就是这么强。这个Bounty当然不会到这里就结束，既然人家相信我，我就认真做，不论最后结果如何。如果你要问为什么，因为人生就是一场冒险，而冒险很快乐！
这个issue有点难，奖金不算低，但加上我只有两个人竞标。
我之前没有写过一行Julia代码。在投票时我也坦承自己没有Julia经验，但做为一个身经百战的老程序员，我想挑战这个问题。更何况，我还有my-ai-team。
当时我就想，体验一下嘛，失败了也没关系，至少还能因此了解Julia语言。
我没指望能被选中，另一个投标者虽然表达兴趣时虽然只写了一小段，但人家多少有Julia经验。
昨天GitHub弹出消息，说恭喜我被选中了，最迟12月8号交活。这下就不得不认真准备了。
因为这个项目是GPT帮我选的，为了不占用Codex流量，我就让GPT先准备第一张票 -- 侦察一下这个issue有多难。我开了一个新仓库 -- BountyLab， 准备工作就在这里做。不知道是不是因为GPT不方便调用gh命令，它说票弄好了，其实它只是在仓库写了一个ticket01.md。但我并没有检查，因为我知道GPT并不是专业的开票agent。它的票肯定不规范，所以我就让我的专业开票员 explorer agent给我“refine #1”。这是我给它的唯一的指令。
这次explorer背后的模型，我指定的是deepseek v4 pro。这次refinement它颇花了些时间，因为这个ticket01.md scope其实挺大。虽然BountyLab几乎是空的，但这个票是侦察票，需要了解我中标的issue到底是个什么问题，牵扯哪些仓库的哪些模块，等等等等。它做了很仔细的调研之后，把这票整理的很规范之后，标上了Ready。这当中令我印象深刻的是，它没有找到#1之后并没有停下来问我，而是翻仓库找到了ticket01.md然后以此为原始需求，精炼之后新建了真正的#1。
我让GPT评价这次精炼，它仔细读了票之后说：
> 你只给了它一句 “refine #1”，而当时仓库里并没有 GitHub Issue #1，只有我留下的 Markdown ticket 和 JuliaHealth workspace。它没有卡在“找不到 #1”，也没有凭空乱造，而是先调查 repo 现有结构、读出我们的意图，再把 Markdown ticket 提升成正式的 GitHub Issue #1。这说明它做了三步很关键的推理：
先识别“#1”大概率指的是已有的第一张 ticket；再从 repo 内容恢复上下文；最后把它重构成更适合 agent 执行和验收的 issue。
这比单纯“润色文字”强很多。尤其它还自己补出了 pinned SHAs、具体 deliverable、acceptance criteria、upstream read-only 边界，这些都不是你那句话直接要求的。
我的评价是9.5/10。剩下那 0.5 不是能力问题，而是工程上我还是会对它加的那两个验收条件做一点去脆弱化，避免 ticket 自己太聪明、反而约束过头。
这其实也挺能说明 my-ai-team 的价值：人给的是意图，agent 负责把意图变成可执行工作单元。 它确实做到了。（我背后偷笑：这当然是我给开票员制定的优秀宪法的功劳）
票Ready了，早已等候多时的delivery agent立即就pickup了票开始施工。这次我用得Planner/Developer是GLM5.3Flash high，而Reviewer是GPT-5.6-Luna xhigh。从15:33分开始接到单，到最后17:29合并。两个agent忙活了两个小时，Reviewer打回去十次，最后批准了第十一版，合并了PR。我拿到了报告。
然后我让GPT评价这份报告，ta的评价是：（警告！！！会看到许多“不是，而是”的GPT腔，我一字未改哦！）
这次我会给 delivery agent + reviewer 这一对组合打 10/10。
最重要的不是“最后报告很长”，而是你真的看到了 review loop 在纠正实质性错误。第一轮 reviewer 抓出的不是格式问题，而是一个会直接把实现方向带偏的架构错误：报告最初认为 plain
LinearOperator 只要 field-wise adapt Mv/Mtu 就安全，但 reviewer 找到 closures 里还 capture 了 vtmp/utmp/wtmp、tmp、pattern，这些根本不会跟着字段一起迁移。这个错误如果没被抓出来，后面第一张 implementation PR 很可能就是错的。然后 agent 又经历多轮把这些地方逐渐磨平：constructor function 和 concrete struct 的区分、pinned SHA、multi-frame state、测试 tier、Metal 实际没有 CI、
DiagOp.equalOps、copyOpsFn、CPU metadata、callable fields、plan reconstruction……最后 reviewer 才给出 APPROVE，而且 AC1–AC8 全部打勾，PR #2 已经 merge，merge SHA 是 f4a48e6c...。我现在尤其认同报告的两个结论。
第一个是：不是所有对象都能“递归 Adapt 一下就完事”。
现在报告已经把世界分成了几类：
- 可以直接结构化适配；
- 必须通过 constructor 重建；
- plan-carrying 类型必须重建 plan；
- closure-captured state 无法从字段恢复时要明确 refuse；
- 一些 CPU metadata 应该故意留在 CPU；
- opaque callable 需要 maintainer policy。
这就已经不是“读代码笔记”，而是真正的 architecture model 了。
第二个是：第一张 upstream PR 的范围已经很清楚。它建议先做
LinearOperatorCollection.jl，只碰 WeightingOp / NormalOpImpl / ProdOp / DiagOp 这几个 plan-free family，而且通过 constructor reconstruction 实现，不碰 FFT/NFFT、不碰 RegLS solver state。这个 slice 我觉得非常合理：小、可测、能验证 Adapt 方向、风险低。我还注意到 reviewer 最终特别确认了：
> first
WeightingOp / NormalOpImpl / ProdOp / DiagOp slice has target-first recipes and preserves DiagOp.equalOps说明这不是 agent 自己“觉得差不多”，而是 reviewer 已经按 acceptance criteria 验过一遍。
所以现在 Ticket #1 真正完成了。
下一步我建议不要立刻写代码。先从报告里的 17 个 maintainer questions 里挑出 真正需要在第一张 PR 前确认的 3–5 个，发给
nHackel。没必要把 17 个全扔过去，那会让 maintainer 很难回答。我已经能看到最值得先问的几类：
1. plan 是否统一要求 reconstruct；
2. closure-captured constructor results 是否都应该走 public-constructor reconstruction；
3.
init! 的 implicit re-templating 是否暂时保留；4. JLArray test tier 是否希望在第一张 PR 里重新启用；
5. Metal 是否可以先不纳入第一 slice。
这几个回答会直接影响 #2 的设计。
这次最让我满意的其实不是 delivery agent，而是你真的让 my-ai-team 形成了“delivery → reviewer 打回 → 修正 → 再审 → 直到通过” 的闭环。Reviewer 打回 10 次，看起来很折腾，但这正是它把一个“看起来合理的 AI 报告”变成“可以据此开始改 upstream”的东西的过程。（又该我偷笑了。4个月2000多个版本发布难道都是我发着玩的吗，平庸模型高质量输出的秘密就是 - 高质量输入 + 独立评审。如果让开发员兼职当审核员，它才不会折腾自己十轮呢！）
my-ai-team就是这么强。这个Bounty当然不会到这里就结束，既然人家相信我，我就认真做，不论最后结果如何。如果你要问为什么，因为人生就是一场冒险，而冒险很快乐！
我初用DeepSeek4.1f觉得它好棒，但一深入使用就好感顿失。大概宣传的太猛，导致我的期望值太高了。我更喜欢0731。有人情味儿，也稳重。4.1想得过多，犯错率还更高。真是令人失望的体验。
glm5.3flash是我的新宠。
glm5.3flash是我的新宠。
今天来说说 CI。CI和测试密不可分。AI爱写测试，也爱运行测试。这很好，但是，随着项目的增长，测试代码越来越多，AI 常常只是把自己变更有关的测试和新测试跑一遍绿了就提交推出了。
新变更可能破坏旧功能。如果有合理的CI，就能很大程度上避免这种问题。CI何时运行，运行哪些测试套件，要随着项目进化在需要时调整。但总起来说，这是你的决定。有CI我们就能让agent自测绿了还不行，得CI也绿了才算数。CI能显著提高PR的质量，把问题消灭在发布之前。
你的项目里有CI吗，如果还没有，那就让你的agent把它搭起来！my-ai-team能充分利用目标仓库里的CI workflow保证高质量的产出。如果你想试试，欢迎查看文档 mat-docs.shukelabs.com
新变更可能破坏旧功能。如果有合理的CI，就能很大程度上避免这种问题。CI何时运行，运行哪些测试套件，要随着项目进化在需要时调整。但总起来说，这是你的决定。有CI我们就能让agent自测绿了还不行，得CI也绿了才算数。CI能显著提高PR的质量，把问题消灭在发布之前。
你的项目里有CI吗，如果还没有，那就让你的agent把它搭起来！my-ai-team能充分利用目标仓库里的CI workflow保证高质量的产出。如果你想试试，欢迎查看文档 mat-docs.shukelabs.com
9 月 11–17 日，个人仓共 183 次提交。主线几乎全周都是 my-ai-team：console / baton / Windows CI / explore，周末才岔出官网 和 bounty lab。
───
2026-09-11 · 23 次
my-ai-team
console 补 loading/busy、状态说明、Rewind 深链；relay 拒重复投递；baton 把头less 按角色串起来，并找回丢掉的 bg-run 回调。安装把 tools/ 踢出 PATH。Windows CI 开始盯 tracker 重复失败。
baton
默认构建收成 harness-only（含 breaking）。
x-auto-poster
免费号 CJK 按加权长度拆帖，补同步未发出的排障。
───
2026-09-12 · 32 次
my-ai-team
console 一天成型：pause/resume、角色栏、行内 composer、时间线带名字。Telegram 接到 local adhoc/audit 和 auto-refine。发版开始在 X 上宣布每个新 tag。Windows 门禁改到私有 Linux runner。
baton
服务状态带 exe/version；外部 agent 超时改成显式无界。
x-auto-poster
/add 可 basic-auth，Firefox 会话过期自刷新。
───
2026-09-13 · 13 次
偏短的一天。quota-gateway 处理 Codex 耗尽 429、热开关 debug 日志。my-ai-team 把测试经济写进宪法，修 owner-record / 闭周期时钟，缩短发版广告文案。
───
2026-09-14 · 17 次
my-ai-team 夜里加 commandcode 无头后端；修 headless 对话被静默替换、quota 的 403 oauth 分类、duo 计划审批只投一次。白天多是测试夹具和 Windows bootstrap 失败原因。
quota-gateway 健康检查和 UI 露出构建版本。
───
2026-09-15 · 16 次
baton 邮箱改按投递序领取，prune 未消费 outbox，daemon 活着与否改看 serve.lock。
my-ai-team 加 mat baton doctor；duo 双角色空闲可恢复；Windows 上 explore/live 的 lean 启动；测试侧收回孤儿 tmux。
───
2026-09-16 · 46 次
一周最密。
my-ai-team
explore 的 unready 精炼改成常驻 worker（倒计时 parked pane、lean、gated queue 日志）。live/codex 接 --domain，commandcode 也能挂。CI Full 一天三次、抽 Linux 工具安装、Windows bootstrap 共享。freebuff 保活；baton 合并 duo 回合消息、死 peer 推迟 stall 恢复。测试开始按 case 报 skip、做 profiling。
mat-site 从零脚手架，晚上接 VibeCafe 埋点。
baton --pretty；按 --registry 把回复打回发送方 inbox。
shuke-labs 发博客 A Handoff Is a File, Not a Message。
───
2026-09-17 · 36 次（今天）
my-ai-team 仍是大头：reviewer 的合入证据搬进 merge-gate skill；Codex 默认走官方网关；freebuff 凭证收敛；parked wait 去 fork；relay 在宣称成功前核对 enqueue。测试库存收成一张计时表。
mat-site 首页改成购买、套餐、客户安装流。
晚上 bounty-lab 立仓，挂上 JuliaHealth 侦察票。
dotfiles 个性文件中文语气，Grok 默认模型分隔符修掉。
───
七天故事：前五天把 mat 的 console、无头 baton、Windows CI 钉牢；16 日起 explore 常驻炼票、官网开张；17 日合入纪律技能化，并抽出半天给客户站点和一份赏金侦察。
───
2026-09-11 · 23 次
my-ai-team
console 补 loading/busy、状态说明、Rewind 深链；relay 拒重复投递；baton 把头less 按角色串起来，并找回丢掉的 bg-run 回调。安装把 tools/ 踢出 PATH。Windows CI 开始盯 tracker 重复失败。
baton
默认构建收成 harness-only（含 breaking）。
x-auto-poster
免费号 CJK 按加权长度拆帖，补同步未发出的排障。
───
2026-09-12 · 32 次
my-ai-team
console 一天成型：pause/resume、角色栏、行内 composer、时间线带名字。Telegram 接到 local adhoc/audit 和 auto-refine。发版开始在 X 上宣布每个新 tag。Windows 门禁改到私有 Linux runner。
baton
服务状态带 exe/version；外部 agent 超时改成显式无界。
x-auto-poster
/add 可 basic-auth，Firefox 会话过期自刷新。
───
2026-09-13 · 13 次
偏短的一天。quota-gateway 处理 Codex 耗尽 429、热开关 debug 日志。my-ai-team 把测试经济写进宪法，修 owner-record / 闭周期时钟，缩短发版广告文案。
───
2026-09-14 · 17 次
my-ai-team 夜里加 commandcode 无头后端；修 headless 对话被静默替换、quota 的 403 oauth 分类、duo 计划审批只投一次。白天多是测试夹具和 Windows bootstrap 失败原因。
quota-gateway 健康检查和 UI 露出构建版本。
───
2026-09-15 · 16 次
baton 邮箱改按投递序领取，prune 未消费 outbox，daemon 活着与否改看 serve.lock。
my-ai-team 加 mat baton doctor；duo 双角色空闲可恢复；Windows 上 explore/live 的 lean 启动；测试侧收回孤儿 tmux。
───
2026-09-16 · 46 次
一周最密。
my-ai-team
explore 的 unready 精炼改成常驻 worker（倒计时 parked pane、lean、gated queue 日志）。live/codex 接 --domain，commandcode 也能挂。CI Full 一天三次、抽 Linux 工具安装、Windows bootstrap 共享。freebuff 保活；baton 合并 duo 回合消息、死 peer 推迟 stall 恢复。测试开始按 case 报 skip、做 profiling。
mat-site 从零脚手架，晚上接 VibeCafe 埋点。
baton --pretty；按 --registry 把回复打回发送方 inbox。
shuke-labs 发博客 A Handoff Is a File, Not a Message。
───
2026-09-17 · 36 次（今天）
my-ai-team 仍是大头：reviewer 的合入证据搬进 merge-gate skill；Codex 默认走官方网关；freebuff 凭证收敛；parked wait 去 fork；relay 在宣称成功前核对 enqueue。测试库存收成一张计时表。
mat-site 首页改成购买、套餐、客户安装流。
晚上 bounty-lab 立仓，挂上 JuliaHealth 侦察票。
dotfiles 个性文件中文语气，Grok 默认模型分隔符修掉。
───
七天故事：前五天把 mat 的 console、无头 baton、Windows CI 钉牢；16 日起 explore 常驻炼票、官网开张；17 日合入纪律技能化，并抽出半天给客户站点和一份赏金侦察。
