AI 时代，不破不立：程序员的旧能力，需要重新编译一次 > 随着 AI 时代的来临，所有涉及到网络的技术类工种，都越来越焦虑。再加上各种自媒体的夸张和渲染，焦虑让人无法呼吸。让人感觉非常焦虑和浮躁。但是焦虑和浮躁的本质原因是什么呢? 怕被取代，这是一个表面现象。并不是问题的本质原因。我的结论是: 怕是对未知事情的不了解。 > 浮躁是想跳过过程直接拿到结果。 - 焦虑是因为对结果的不确定性。 >...
aweiai-gf-169.webl 一行一行看代码的时代结束了，程序员要开始对结果负责 前言 AI 时代，程序员需要调整的可能不只是开发工具，还有我们看待代码、责任和个人价值的方式。 当然，这并不是什么行业共识，也不是一个已经被证明的标准答案。只是小编最近使用 AI 开发时，越来越明显地感受到：过去那套逐行编写、逐行阅读、逐行确认的工作方式，已经有些跟不上 AI 生成代码的速度了。 过去，小编也...
一套工作流连续推进到第十二篇文章，很容易让人产生错觉：既然流程能跑，模板就已经成熟，可以原样复制到所有项目。 磁盘上的材料给出了更克制的结论。前十一篇都经历了独立审阅，四篇需要修订后复审；项目规则、角色、交接、验证和恢复演练都有真实文件支撑。但这次贯穿对象仍是 JVS 内容生产流程，并没有在另一个真实业务仓库完成一次功能修改或重构。配图和发布也没有进入本轮授权范围。 小编现阶段的判断是：可复用的不...
“接着上次继续。” 任务刚暂停几分钟时，这句话似乎没问题。时间一长，或者换了线程、角色，当前上下文里未必还保留那次执行的完整细节。更危险的是，磁盘已经发生变化，模型却沿用旧计划：重复创建文件、再次发送外部请求，或者把用户后来改过的内容覆盖掉。 小编现阶段的判断是：恢复不是找回一段完美记忆，而是从可信检查点和磁盘事实重新回答三个问题：现在到底是什么状态，旧授权还剩多少，下一步怎样做才不会重复破坏。 ...
“修改完成，检查通过。” 这句话最多说明执行者愿意结束当前阶段。它没有说明运行了什么检查，检查覆盖哪些文件，结果是否完整，也没有回答计划里的完成条件是否逐项满足。一次命令返回 0，甚至所有测试变绿，都可能与用户真正要交付的结果隔着一段距离。 小编现阶段的理解是：验收要从预先定义的完成条件出发，为每个结论寻找对应证据；模型的完成声明只能作为待核线索。 有一项关键条件缺少证据或检查失败，结论就应停在“...
计划写得很完整，真正开始改文件时，Codex 仍然可能走偏。它可能按文件名猜实现位置，顺手修掉范围外的问题，做到一半忘了更新状态，最后只返回一句“已经完成”。代码或文章也许真的改了，但我们很难回答：为什么改这里，实际改了什么，哪一步检查过，偏差又留在哪里。 在小编看来，受控执行的关键是让每次动作都能指回目标、仓库事实和当前完成条件。 这不等于实时盯着每一行，而是从开工前的基线开始，保留一条足以解释...
“文章已经规划好了，请继续处理。” 这句话对刚参加完讨论的人似乎够用，换一个 Agent 就不够了。它不知道“文章”是哪一篇，规划写在哪个文件，用户确认了正文方向还是只确认了章节，前一个角色做到了什么，又有哪些事实没有核验。接收者只能翻聊天记录、猜路径，或者拿一句含糊授权继续往下做。 小编现阶段的判断是：Agent 交接要传递的不是一段对话气氛，而是一份可以重新核对的任务现场。 聊天历史可以辅助理...
“你是一位资深架构师，拥有二十年经验，思维严谨。” 这段人设可以改变语气，却没有回答最基本的工程问题：它负责哪一段任务，需要先读什么，能修改哪些对象，什么事情不能做，完成后留下什么，失败时又该返回给谁。换成“测试专家”或“安全大师”，问题依旧存在。 小编现阶段的判断是：专业 Agent 的最小单位不是人物性格，而是一份可以独立执行、独立验收的阶段责任。 名字方便我们称呼它，职责边界、输入、动作和产...
一个内容项目每次都要经历主题调研、正文写作和独立质检。我们可以把整套流程写成一个 Skill，也可以给三个 Agent 各起一个名字。两种方案都能跑起来，但很容易出现另一种问题：Skill 越写越像总指挥，Agent 只是换了称呼继续做同一件事。 小编现阶段的判断是：先看我们想复用的是工作方法，还是想分离一份责任。稳定方法交给 Skill；需要独立判断、独立上下文或独立产物的责任，才值得拆成 Ag...
假设我们让 Codex 修复一个依赖版本问题。它既可以读取锁文件，也可以运行包管理器；既可以查看官方文档，也可能访问代码托管平台；连接器已经登录后，甚至还能创建 Issue 或提交远端变更。 工具列表很丰富，却没有告诉我们下一步该用哪个。小编现阶段的理解是：先说清任务需要什么证据，再选择能用最小权限取得该证据的工具。 工具能力只表示一条路走得通，操作半径仍要由目标对象、副作用和恢复成本决定。 上一...
“把登录模块整理一下，测试也补上。” Codex 调查后发现两条路：一条只整理模块内部结构，另一条顺便统一身份模型，但会牵动数据库字段和三个调用方。它该直接选择看起来更彻底的方案，还是把搜索代码、运行检查、修改文件都停下来逐项请示？ 两种做法都有问题。前者替用户决定了任务目标，后者把协作变成不断点“同意”。小编更愿意把确认门禁理解成一个决策点：当下一步可能改变结果定义、越出已有授权，或者留下难恢复...
“帮我重构一下这个模块。” 这类需求足够让 Codex 开始搜索代码，却不足以支撑一次中等复杂度的交付。重构要解决什么问题，哪些行为不能变化，涉及几个模块，做到什么程度算结束，都还没有答案。直接开工后，每一次新发现都可能把任务带向另一个方向。 小编现阶段的判断是：复杂任务里的计划，不是提前猜出所有步骤，而是把目标、未知项、依赖、完成条件和当前状态摆到台面上。这样 Codex 才能知道下一步，用户也...
上一篇文章给仓库补上了稳定规则。接着往下做，很多人会产生一个很自然的想法：既然缺上下文会让 Codex 猜，那就把架构文档、历史 Issue、测试日志和相关代码一次性都交给它。 短任务里，这种做法偶尔有效。项目一大，问题很快换了方向：旧文档与当前代码冲突，失败日志挤在真正的错误前面，一份临时评审意见又被当成长期要求。Codex 没有“少读”，却依然可能做错判断。 小编现阶段更倾向于把上下文看成一次...
让 Codex 修改一个函数并不难。麻烦通常出现在任务变长以后：它改对了眼前的代码，却用了仓库不接受的命令；修好了功能，却碰了不该动的生成文件；说测试通过，跑的却不是项目真正的验收入口。 这些表现很容易被归结为“模型不稳定”。小编现阶段的理解是，其中一部分问题发生得更早：仓库没有把稳定的项目事实和行为约束交代清楚，Codex 只能从文件名、常见目录和当前对话里猜。 所以复杂任务的第一步不该是继续补...
Grill Me 的本质：不是让 AI 多提问，而是把想法变成可验收的任务 07311814.webl 前言 最近研究了 Matt Pocock 的 Skill。它的内容非常短，核心逻辑说白了就是：让 AI 围绕一个计划持续追问，每次只问一个问题，并且给出推荐答案，直到双方对这件事形成共同理解。 第一眼看上去，这不就是让 AI 多问几个问题吗？好像自己在提示词里加一句“如果有不清楚的地方先问我”...
作者: 西魏陶渊明 博客: > 天下代码一大抄, 抄来抄去有提高, 看你会抄不会抄！ @[toc] 一、目标 通过前面几篇文章的学习,我们已经完成了通信层的建立,如下我们可以通过下面代码实现服务间的通信。 server() 使用Mojito构建一个服务端, 绑定 6666 端口。 - clientSync() 使用Mojito构建一个客户端,连接 , 发送一条任意请求。 实现通信只是第一步,下...
作者: 西魏陶渊明 博客: >天下代码一大抄, 抄来抄去有提高, 看你会抄不会抄！ 一、前言 如果不是因为热爱，我不会这样；如果不是为了，涨点粉丝，我不会这样； 如果不是为了几两散碎银子，我更不会这样。 以前的文章开场太过严肃，太过专业。就像大学老师上课，只知道讲课。不知道互动。这样 效果太差，写的没意思，读者更是没意思。大数据分析还以为你是抄的，还不给你推荐热门 😭。 不然就改变一下风格吧，...
20260731.webl 一、入门：临时召集几个智能体并行工作 入门阶段不需要写配置文件，也不需要创建自定义智能体。 只要在提示词中明确要求 Codex： 启动几个子智能体；每个智能体负责什么；是否等待全部完成；最后如何汇总结果。 例如： 这已经算是在使用 Codex 的高级能力了。 1. 最适合并行的任务 子智能体优先适合互不依赖、以读取和分析为主的工作： 分别检查前端、后端和数据库；分别检查...
高并发系统设计（一）：减少请求，不只是加缓存 前言 系统出现性能问题时，我们很容易把注意力放在“如何处理得更快”上。 接口慢了，就优化 SQL；线程不够了，就调整线程池；机器扛不住了，就继续扩容。这些方式当然有用，但它们都默认了一个前提：进入系统的每一个请求，都应该被完整处理。 实际上，这个前提并不成立。 同一份数据可能正在被反复查询，超过系统容量的流量可能已经没有能力处理，一个请求内部也可能包含...
这三种方法解决的是同一个问题：同一种物料分批采购、每批价格不同，出库时到底按什么单价结转成本。 假设： 月初库存：100 件，单价 10 元 本月采购：100 件，单价 12 元 本月先后出库：50 件、100 件 1. 移动加权平均法 每发生一次入库，就重新计算库存平均单价；后续出库按最新平均价计价。 第一次采购后： 移动平均单价 =（当前库存金额 + 本次入库金额）÷（当前库存数量 + ...