maolon 最近的时间轴更新 maolon 最近的时间轴更新 |
maolonV2EX 第 442547 号会员，加入于 2019-09-22 10:16:39 +08:00今日活跃度排名 669 |
| Claude 4.5 (feat: claude desktop), 一款最像人的 AI： In a bad way Claude • maolon • 2025 年 10 月 3 日 • 最后回复来自 xiaket | 9 |
| codex pro plan 使用一周感想 程序员 • maolon • 2025 年 10 月 15 日 • 最后回复来自 mogutouer | 27 |
maolon 最近回复了
4 小时 3 分钟前 回复了 jolly336 创建的主题 › 人工智能 › AI-关于移动端自验证能力的疑问？ |
@jolly336 你说的很有道理，如果要考虑泛化和可维护确实是一个挺难的问题，不过我觉得 runbook 的方法可能还是可行的（可以针对每个 app 一个 runbook ），从人维护变为使用 agent 来维护这个 runbook 里的路径，你只需要启发式的告诉这个维护 agent 需要检查哪些东西，甚至可以让他自行检查代码库和意图来写维护这个文档，人只做最终审核。
4 小时 7 分钟前 回复了 jolly336 创建的主题 › 人工智能 › AI-关于移动端自验证能力的疑问？ |
@Dabney 对不起，没有啥最佳实践，只能算是在摸索这方面
9 小时 9 分钟前 回复了 287854442 创建的主题 › Joe's Talk 🪐 › 一个大胆的预言：语音输入将成为绝对主流 |
这不是一个场景，我打字的时候我其实在脑子里在思考和调整思路和逻辑，并且很方便的来回修改，语音你再依赖 ai 语义理解，你在思路都没想好就说也说不出个什么所以然来，这不是准确度的问题而是使用习惯的问题
1 天前 回复了 jolly336 创建的主题 › 人工智能 › AI-关于移动端自验证能力的疑问？ |
我最近在开发 app ，感觉最简单朴素也是最实用的方法，直接写一个 e2e run book 的 md 让他读这个 file 然后按照固定行为检查（调用模拟器的 mcp ）。
另外 token 消耗这个问题基本无解，就算是现在配置过的 mcp 只返回文字 layout 和按钮 id ，在关键步骤他还是要截图然后 agent 这边读图，依然是很烧 token 的行为（不如说自动化测试就没有不烧 token 的），好消息是未来 token 会越来越便宜，变成随便烧也没事的状态
另外 token 消耗这个问题基本无解，就算是现在配置过的 mcp 只返回文字 layout 和按钮 id ，在关键步骤他还是要截图然后 agent 这边读图，依然是很烧 token 的行为（不如说自动化测试就没有不烧 token 的），好消息是未来 token 会越来越便宜，变成随便烧也没事的状态
2 天前 回复了 alioth0909 创建的主题 › 问与答 › 始终 get 不到 Gemini 3 到底强在哪里？有没有大佬能指点下？ |
gemini 现在比别家遥遥领先的就一个能力：他多模态可以原生读视频，甚至可以通过 url 直接读 youtube 视频，如果有这方面需求他就是无可替代的
3 天前 回复了 levin56 创建的主题 › Vibe Coding › 现在 Agent 的写代码的成本不低啊 |
而且你这个计算的方法也有问题，用 agent 哪有直接算 api 价格的不都是用包月套餐/api 转发的？，要你这么算的话五个月用了五千多刀，我用的起么
4 天前 回复了 walterggg 创建的主题 › 程序员 › 这个 workany 是什么水平的项目，有大佬讲一下吗？看他的介绍我一句也看不懂；网站： https://github.com/workany-ai/workany |
another claude code wrapper ui/app?
6 天前 回复了 YanSeven 创建的主题 › 程序员 › 对 llm 的感性化感叹：师者，传道授业解惑也。 |
所以 stackoverflow 就是这么被干死的：
一边是各种规矩一言不合 downvote/duplicate topic 的 toxic 人类，
一边是不论你问多小白多愚蠢都耐心解答的 ai
于是 stackoverflow 成功回到了他 2008 年的发帖量
一边是各种规矩一言不合 downvote/duplicate topic 的 toxic 人类，
一边是不论你问多小白多愚蠢都耐心解答的 ai
于是 stackoverflow 成功回到了他 2008 年的发帖量
7 天前 回复了 iso223 创建的主题 › 职场话题 › 刚出社会的学生能不能珍惜一下工作啊 |
我觉得还是要区分什么是卷和怠工的区别，这位老弟明显是在正常工作时间，正常的工作安排下故意拖时间不完成，拖慢团队进度而不是所谓的什么“不卷”。
我的提问就是难道你们团队不设置什么 kpi 或者 okr 的么？他这么弄一次不完成，两次不完成，你直接向上报告喜提 PIP 而不是观察半年才做艰难决定。
我的提问就是难道你们团队不设置什么 kpi 或者 okr 的么？他这么弄一次不完成，两次不完成，你直接向上报告喜提 PIP 而不是观察半年才做艰难决定。
7 天前 回复了 yukinotech 创建的主题 › 程序员 › 请教一个 openspec 问题 |
1. 文档即代码，是的你的理解没错
2. spec 主要是充当计划的文件化索引。
你的 agent 开始工作的时候一般都会启动一个 planner 然后开始计划并拆分的任务，当前 agent 驱动的大模型上下文太短，所以我们会在工程化里大量使用 compact 系统（包含 tool compact, history summrization 这些功能），这些 compact 系统会压缩上下文，导致信息丢失，(比如一开始 planner 详细的规划了要实现哪些细节需求，而在多次 compact 后这些细节丢失了），然后 agent 就会开始自由发挥。
如果我们了解 compact 的工作原理就会发现，比如 tool compact 是将 tool 返回的结果存在一个文件里（比如 xxx.log ）然后将上下文里 tool 调用的那一条 message 改为 {is_compacted:true, file_path:"xxx.log"}，那么如果 agent 需要重新查看之前的结果，他就能通过读取 file 无损的调用回 tool 的返回内容。
spec 也是同理，它充分利用了 agent 的 compact 系统会最大程度保留文件 path 的特性，从一开始就文件化了 planner 输出的细节，在多次 compact 后虽然需求被多次压缩损失，但是只要这个文件索引地址还在，agent 就能在需要的时候重新读取细节，从而保证在多任务，很长的工作流程里，细节和讨论的一致性，这就是 spec 的目的
3. 这是自主性的问题，你希望 agent 拥有多少自主权利，比如你允许他部分 design 一些页面的组件吗，还是你一点自主性都不允许，这是你对项目的预期和控制问题，不是 spec 的问题
2. spec 主要是充当计划的文件化索引。
你的 agent 开始工作的时候一般都会启动一个 planner 然后开始计划并拆分的任务，当前 agent 驱动的大模型上下文太短，所以我们会在工程化里大量使用 compact 系统（包含 tool compact, history summrization 这些功能），这些 compact 系统会压缩上下文，导致信息丢失，(比如一开始 planner 详细的规划了要实现哪些细节需求，而在多次 compact 后这些细节丢失了），然后 agent 就会开始自由发挥。
如果我们了解 compact 的工作原理就会发现，比如 tool compact 是将 tool 返回的结果存在一个文件里（比如 xxx.log ）然后将上下文里 tool 调用的那一条 message 改为 {is_compacted:true, file_path:"xxx.log"}，那么如果 agent 需要重新查看之前的结果，他就能通过读取 file 无损的调用回 tool 的返回内容。
spec 也是同理，它充分利用了 agent 的 compact 系统会最大程度保留文件 path 的特性，从一开始就文件化了 planner 输出的细节，在多次 compact 后虽然需求被多次压缩损失，但是只要这个文件索引地址还在，agent 就能在需要的时候重新读取细节，从而保证在多任务，很长的工作流程里，细节和讨论的一致性，这就是 spec 的目的
3. 这是自主性的问题，你希望 agent 拥有多少自主权利，比如你允许他部分 design 一些页面的组件吗，还是你一点自主性都不允许，这是你对项目的预期和控制问题，不是 spec 的问题
Select Language