套条时序比较接近 更方便 xmp 吧

如果只是把 agent 当作 chatbox 那这个结果是可以理解的。好像从 op 的描述没看到基本的 coding test review 的 loop ，只是让 agent 写 不设定边界，没有沉淀文档资产，agent 也没有验收锚点，结果就是到处发散

我都从来不让 agent 的用户组跑 docker 不允许执行 DDL ，rm 之前要用户决定

@jony83 随机本身就是可以量化的啊 要不然概率论与数理统计还有测度论是研究什么的？和有没有生命参与没关系。大数据杀熟怎么来的？通过建立用户画像，对用户的行为进行量化的统计分析，预测用户接下来的行为，从而进行针对性的推送和参数修改，这本身就是成功的

量化只是说能用数值、通过数学建模、或者用概率来描述对象的部分属性，但量化这种手段不等于能够精确预测结果。我可以比如对一个路口的车流量、一个店面的人流量进行统计分析，建立一种泊松分布或者更复杂的什么概率分布，但是只能在概率意义预测某个时间段下可能的车流量人流量。你可以预测一个概率模型的结果空间，但是你不能精确说下次一定是什么结果，即使概率 100%也不一定发生，0 也不一定不发生。
意识本身可能不是量化的 但是不代表不能被量化，量化本身也不能精确预测结果

现在做 SEO 意义还大吗 我看网站日志基本上都是被各种 aibot 爬 大部分流量可能都是 ai 搜索爬的

医生还能熬 码农每天都在职业生涯倒计时

我觉得辩证唯物主义也是一种信仰吧 至少我一直用它来解释世界

这个标题我怎么好像前几天在 L 站看到差不多一样的

用 SDD 来管理需求呢？把各个需求 改动 规范什么的沉淀成 docs,然后在 agents.md 下给索引 让模型按需读取。这样 session 隔离也能降低会话级别上下文的影响

感谢无常分享，学到了好多东西。除了具体的技术细节，谈谈印象深刻的一些点和疑问。(刚刚手滑发出去了一条
1.首先是 RAG 的量化经验，我直觉也是 recall90%挺好 没想到 recall 要 97 可能才够那还是很难的
2.有个疑问是，OpenClacky 追求极致 cache 命中率，我看用到了很多对于 prompt 的优化，包括 double buff 之类的，能够做到极致的缓存命中率和低成本。但是用户可能比较担心 cache 命中率提高但是效果变差了，似乎没有看到大规模数据集下的效果，大概看了一下 benchmark 可能更多是一些孤例的分析，能不能衡量更丰富的场景？
3. 期待能够把技术报告分享到 arxiv ，不知道有没有类似的计划呀？感觉你们的工作挺有意思的，发技术报告也是宣传的一种渠道

感谢无常分享，学到了好多东西。除了具体的技术细节，谈谈印象深刻的一些点。

@maocat 看来不是个例了 上次让 qwen3.6plus 改一个前端页面 简单的需求直接来一句“I accidentally deleted too much. Let me rewrite the file properly.”误删了大批量代码

劝不听就算了 要不然她到时候选了你说的道路 有任何不满都会怪你当初强硬让她这么选择。成年人了自己负责

从来不用这种浏览器 电脑 chrome/firefox 安卓 via

老登 Java 后端现在受影响也不得不去学前端了 大趋势都是转 ai 全栈

差不多。现在就让 subagent 调 skill 来 review,然后换个模型交叉验证一下没有 blocking issue 就懒得看了

谢谢老板 在用 qwen3.6plus 第一次试试看