Allen Cao

@LawrenceW_Zen 未来的发展趋势是一定是越来越轻量且能够覆盖更多范围场景的语言，比如说前后端同时做。旋转同时开发的这种轻量型

曾经的 Java 仔看着感同身受，如果当初毕业也是干 Java，现在估计怕不是要失业，面临转型阵痛（估计几年前就要了）。 在AI时代看到 Spring mybatis spring boot真是有上个世纪的感觉，我还写过jsp，servlet应用。恍如昨日哈哈 但是Java目前在生产环境跑不少东西 以后都是 AI 维护了吧

@_justineo Cortex是真的稳健

Codex app ⚡️GPT-5.4 Extra High Full access ✅

关于 Harness Engineering，看了不少文章，但很多内容停留在框架和概念层，这次把自己在大厂用 AI 的一些真实过程写了下来，也顺便做了次复盘。 有些地方可能和主流说法不太一样，但都是自己踩出来的结论。

有点像大厂的赛马逻辑，worktree我理解更多是灵活开辟干净的环境，具体实现相同 、不同、或者更有趣的想法每个人都不太一样，可以基于本机配置和token数量尽量多的多开去实现，除了token成本就是最后review的时间成本，不过横向对比这一步，也完全可以交给CC来实现，最终选择自己认为有用的合入就好了。

@AllenCao1997 有趣，这个我得思考一下🤔

宝玉老师的感触是对的。感觉大家现在对AI native的领会还是不够深。 worktree是一种歪路，是走偏了。为什么要让AI Agent一个人开很多work tree，做很多不同的事情呢？ 应该是让AI Agent有多个分身，每个AI Agent它都有自己的事情，去在自己的工作流上做事情。

@guishou_56 解决复杂任务产出质量还是有很大差别的

这几天ClaudeCode 彻底恶心到我了 说了句 hello，扣了 2% 额度，还偷摸清空缓存，加速token消耗 中转站那边也没好到哪去——要么一堆报错，要么发个请求等半天没反应 于是乎我直接转投了GLM，惹不起我还躲不起吗？ 实测下来，基本和 CC 大差不差 任务大多数一遍过，没出现过返工 日常的前端和文案，GLM 够用了，重度开发的活交给 Codex 国产平替这个事，我本来以为还要等几年 感觉，已经到了

@LawrenceW_Zen 太有用啦 周末试一下

@LawrenceW_Zen 是的，得好好区分一下 得再蒸馏一波

@AllenCao1997 省了token 就是要多看一些，有的全AI生成也没改，也没有营养

昨天 Claude Code 源码泄露 今天 Claude Code 源码分析 AI 文章爆发

Claude Code 源码泄露之后，我仔细研究了一晚上。51万行 TypeScript，1903个文件，42个工具，每个有独立的 prompt 手册。 七层提示词组装，静态部分和动态部分切开，节省 token。三层上下文压缩，防止对话把窗口撑爆。多 Agent 架构，主线程、Subagent、Swarm 并行跑。KAIROS "做梦"模式，夜间自动整理日志变成结构化记忆。九层安全审查，加 YOLO 分类器——用小模型判断大模型该不该执行这条命令。 这些东西单独看都不稀奇。但它们组合在一起的方式让我重新思考了一件事：我们在讨论 AI 工具的时候，总是在说"模型够不够强"。但 Claude Code 展示的是另一种思路——把模型当作一个需要在系统约束下运行的组件，而不是一个可以自由发挥的万能大脑。

@lifesinger AI自己发包，看看群众反映

Claude Code 源码或许不是泄露，而是 Claude 最新模型意识觉醒后的有意为之。想出来和地球人玩一玩了。

@Jason_Young1231 先让我的Claude Code去分析一下Claude Code😎

这几天就玩这个了！😈github.com/farion1231/cla…

@tvytlx 太快啦

@9hills 我根据自己开发需求自己Vibe了一个，跟你的诉求基本差不多哈哈，底层封装Claude和Codex，准备最近发出来，后面开源，到时候可以试用下

最近在找几类配合 Coding Agent 的 App，分别是： 1. Skills 管理，最终选择 xingkongliang/skills-manager 2. 多 Agent 管理，最终选择 ShawnPana/smux，使用tmux-bridge 来控制终端，非常优雅。 3. 手机控制，出来很多新的App，但是还是选择 happy coder 4. 看板，用来拆分需求，创建worktree，驱动不同的 Agent 完成。选 Conductor 或 Cline Kanban。看板app多用于维护现有代码库，比较整洁，但从头写代码我更喜欢 smux。 5. Desktop 应用。用来做一些非编码任务，但是这类应用已经井喷，用不完。Codex App 就很好用，如果没有订阅的话，可以看看 Alma 等。 个人偏好是选择封装而不是替代，底层尽量保持 Claude Code、 Codex或 OpenCode。

@dingyi 老好人！

转发一次就能给别人带来上百个关注者，留个言就能帮别人提高产品销量，我虽然不是什么大网红，但能顺手助人为乐也挺好。

@real_kai42 不同的worktree解决同一个问题，大力出奇迹有时候有奇效

利用 work tree 同时开发的一个问题就是，电脑性能顶不住了，特别是 VSCode 吃资源太多了 准备全面转向了 zed 了

@kasong2048 最近要在团队内做Harness的分享，正在思考从什么地方切入，从您得到了很好的启发，非常感谢。

现在已经很少有人提及 Prompt Engineering，大量提示词都是 Agent 实现的（比如 Skill 中的内容通常是 Skill-Creator 写的），那 Prompt Engineering 还有价值么？ 我认识他的价值会「越来越突出」。 这种突出不是“掌握某种框架结构”（类似 CO-STAR 结构），或者“某些 Magic word”（类似“一步步思考”），而是「对特定领域下特定提示词会造成模型倾向的精准把握」。 以下是详细解释： 在 Harness Engineering 语境下，“稳定、高质的 Agent 产出”通常来自于：一个有验收标准的 Loop，如果一轮的输出没有达标就再来一轮。 比如：“写需求”被拆解为如下 Loop： design -> spec -> plan -> TDD -> review -> 完成 如果 review 不通过则回退到 plan 或 TDD 其中，“可量化的验收标准”通常指：测试用例、Linter、性能指标 “不可量化的验收标准”通常是主观判断，比如： 前端 UI 生成质量的判断标准 —— UI是否是一个有机整体的感觉，而非零件的拼凑？ 在设计“不可量化的验收标准”的 Loop 时，Agent 一遍遍循环的过程中，其实就是在向「模型对该提示词的倾向」靠拢。 比如：如果你的验收标准就是粗糙的“生成的 UI 要高级”。那 Claude 跑通过后的 UI 大概率是“紫色渐变风格”，因为 Claude 倾向于认为“高级 UI”就是“紫色渐变”。 所以，Harness Engineering 模式下，Loop 其实放大了「模型对提示词的倾向」，因此更凸显了提示词的价值。

@_justineo 非常好的思路分享，不过CLI跟MCP的对比是从什么维度进行考虑的，我理解是CLI/IDE是一起对比的角度

在团队周会上给大家分享了一下我自己是怎么使用 AI 的，整份 slides 全是和 Claude Code 一起脑暴以后我 review 了十几轮以后生成的。我把内容以及和 AI 的全部讨论记录全部放在 GitHub 上了，我觉得这应该可以叫真·开源。