LimboAI

@limbopeng · 2026-09-12

V2EX 上有个热帖问：Vibe Coding 的代码怎么放心上线？ 我最近面试的过程中，也有老板这样问。 评论区给出的方案也五花八门，大概只有这几种：让 AI 自己做自动化测试、让 AI 做 Review、人工 Review 等等。 这确实是一种心理变化。把 Vibe Coding 的代码安全地推向生产，本质不是彻底消灭 bug，而是将工程重心的控制权从编码实现，转移到契约约束与确定性验证上。 为什么在没有 Vibe Coding 的时候，我们敢于上线？说白了，其实是心里有一个全局感。Vibe Coding 会造成这种全局感的缺失，那怎么弥补这种全局感呢？ 1. 高层次方案 review：首先，从高层次要看一下给出的方案文档是否 OK。这部分没法让 AI 帮你决策，还是要自己 review，然后再和 AI 讨论，直到这些方案你已经烂熟于心。 2. 编码实现与端到端测试：对于编码实现，直接在工地做。做完之后，除了一些单元测试之外，还要做端到端测试和一些对抗测试。因为单元测试很容易让人产生虚假的安全感，AI 会基于它已经写出的错误假设来编造断言；这些看起来正确的单元测试，往往挡不住真实的线上问题。 3. 静态类型与 CI/CD：AI 生成代码的编辑成本趋于0，但人眼逐行 review 很难做到。所以防御必须依赖高杠杆的确定性攻击链，比如严苛的静态类型、CI/CD 等等。 4. 权限最小化、灰度发布与全链路感知：最后一点还是要控制权限最小化，做好灰度发布和及时回滚，以及全链路 trace 和全链路感知。 关于 4 这部分不管在 Vibe Coding，还是没有 Vibe Coding 的时代，都是应该去做的。只不过你做得越好，就越敢频繁上线。 https://www.v2ex.com/t/1241529

lifcc

@mylifcc · 2026-09-13

想了解Agent机制的有福了，最近看到一个很值得看的开源项目： Designing Multi-Agent Systems 它教的是： 如果不依赖现成框架，一个 Multi-Agent Runtime 到底该怎么设计。

LotusDecoder

@LotusDecoder · 2026-09-15

又阅读了很多文章和实操后， 最近关于AI软件工程一点思考是： - 人是看不完代码的。 古法时代，流动性高的大型公司或大项目里，是已有的现象。AI编程时代将这个扩大到了更多人。 - 因为人看不完，但还是要形成一个不那么完备的对当前要改动的代码的“理论”，也有人称之为系统性的视图，也有人称之为 概念完整性。这里是人要因为这一次软件需求，对齐代码，否则AI会失控变成温彻斯特房屋。 - 最好使用 e2e 测试，搭建尽量真实还原的场景做测试，降低对AI自己随手写的mock测试的信任。

Jerry Fang

@Jerry_fsy · 2026-09-18

做AI Agent已经半年了，从最初的懵懂到现在可以交付生产级的Agent。在这个过程中，对Agent的理解逐渐加深。 现在回看，对Agent理解的一个转折点是在微信公众号上看了不少“三元同学”写的文章，逐渐对上下文等概念有了清晰的理解。后来，买了她在Sitor上面的课程，系统学习了Agent。在这些基础打牢后，现在吸收理解包括AI Inference，Agent评测这些知识就更容易了，也是体会一把知识的飞轮。 如果大家对AI Agent感兴趣，可以在公众号上关注“三元同学”，下面附一些我感觉不错的文章： 1.https://mp.weixin.qq.com/s/h5QyZ07G7Kj9xi2gUTltMw 2. https://mp.weixin.qq.com/s/ViQU8mCuLFjLwziOZShhvw 3. https://mp.weixin.qq.com/s/N1WgUN8ddXrw0p0o5IiykA 对AI感兴趣的朋友可以多交流交流。

Erwin

@ErwinWu000 · 2026-09-14

学习了一下Viking老师 @vikingmute 关于E2E验收的博客，收获满满！下面结合我自己的体验，来跟大家分享一下 E2E 的知识 1️⃣ E2E是什么，为什么需要E2E E2E（End-to-End，端到端测试） 是一种模拟真实用户在浏览器中完整操作的自动化测试方式。 它相比代码的单元测试更注重整个端到端的用户操作体验，验证的是整个交互流程能不能跑通。所以它涉及到的模块是非常多的，是整个产品最后呈现的最直接的体现 2️⃣ 如何把E2E引入你的流程 在设计一个新的 feature 的时候，你就需要知道用户是以什么样的形式和路径来进行交互的，这是 E2E 最直接的参照。 Viking 老师提出在写 spec 的时候，就需要先想好 E2E 要测什么，用自然语言描述：打开哪个网页、点哪里、希望看到什么。 在写完代码之后，加入一个 test 环节来专门写 E2E 测试用例。 所以在 spec 那边先定义好测试的大概内容和路径是什么，到 test 阶段再去详细写测试用例。 3️⃣ 用什么工具执行E2E测试？ 其实最常用的 E2E 工具还是 Playwright。它是最底层、最直接的，可以根据需求来写断言，测试方法非常直接。 但因为 Playwright 算是比较“古法”的自动化测试，需要先把整个页面的结构、UI 元素等都确定下来，才能用它去跑回归的 E2E 测试看有没有问题。在进入这种自动化回归之前，前提一定是页面的整体结构已经稳定、没有大改动了才跑自动化。 那怎么去验证页面结构是不是已经稳定了？ 这时候我们会用到一些 AI 的 E2E 框架，比如 agent-browser 和 EgoLite。它们通过语义化、精简的 Accessibility Tree 以及简洁的引用，给 AI 输出当前页面的结构。而且它的 AI-first 设计能赋予 AI 自动化探索和页面随机操作的能力。 这套方案非常适合在自动化验收之前，先走一遍探索性测试；等确认页面没有什么大问题了，我们再接上 Playwright 的 E2E 测试去做回归和 CI 4️⃣ 什么时候执行E2E测试？ 首先我们需要知道，E2E 是跨整个系统端的一个测试，它是把系统的所有子模块放在一起来看最终的流程效果。因为涉及到的面比较广，所以跑 E2E 会很慢，而且需要整个系统的依赖都完全配好。 知道这些基础概念之后，跑 E2E 通常分为几种情况： 1. 推出新的 feature 时：只需要跑 feature 相关的 E2E 测试就好，其他不相关的文件，跑轻量的检查就够 2. 版本发布之前：需要跑全量的 E2E，保证全部功能都是完善的。 3. 对系统进行大重构之后：肯定需要保障重构完的系统是完善的，这时候也要跑全量 E2E。 原文在评论区，感兴趣的朋友自行阅读👇

sunmer

@sunmer575399 · 2026-09-14

推荐一个我最近一直在用的开源项目system-design-primer，360.2k star 1️⃣ 把大型系统设计从零讲透，缓存、分片、消息队列挨个拆开讲，不是丢概念，是告诉你为啥这么设计...配合真实架构图看，比刷面经八股强太多 2️⃣ 附带Anki记忆卡，把核心知识点做成可复习的卡片，通勤路上刷刷，面试前突击特别顶，我上次临场就被问到CAP取舍 3️⃣ 覆盖二十多个真实系统拆解，Twitter、YouTube这类怎么扛住流量，一步步推演给你看。学完能自己画架构图，不再是背答案 有技术基础的可以二次开发，小白照着文档跑也行。 这项目火了快两年还能常年挂在GitHub趋势榜，很多大厂内部新人的系统设计培训材料，底子就是这套东西。 你要是准备跳槽或想搞懂后端架构，花两小时过一遍能省下买课的钱。 我身边好几个转岗的兄弟靠它补齐了架构这块短板，现在面试底气明显不一样。 建议先收藏，哪天用得上直接翻。 你们平时啃系统设计都看啥资料，有没有比它更狠的？ 🔗 https://github.com/donnemartin/system-design-primer #开源 #GitHub

Gangqiang Yao

@yaogangqiang · 2026-09-15

上一条说，只靠测试不能保证软件质量。这条先聊也应该怎么写测试，因为这是基础。下次聊关键设计，以及 review 应该看什么。 针对业务项目，我的理解大概是这么几条： 1 测试行为，不测试实现。比如重复下单不会重复扣款，而不是某个方法调用了几次。业务没变，重构一下测试就碎一地，那多半写错了。AI 特别容易写这种测试。 2 用 BDD，先写验收场景，再写代码。测试描述统一用 user 开头，用 Given / When / Then 描述，用户和 PM 也能看懂。别让 AI 写完代码，再照着自己的实现证明自己没错。 3 禁止 mock。Redis、PostgreSQL 能用真的就用真的，外部系统不好接就注入 fake，但要校验它和真实系统的契约。时间逻辑用 fake timer，别 sleep 几秒再祈祷。AI 真的太喜欢随手 mock 了。 4 我倾向大部分写 E2E，从用户入口走到可见结果，外部依赖可以 fake，实在不合适再写其他测试。测试多了就分级，按改动和依赖关系精准测试，定期完整跑。别改两行代码，等 CI 半天。 5 前面做好了，再看分支覆盖率，先定个 90%。但重点是剩下的为什么没测，尤其是失败路径，别让 AI 为了凑数字再写一堆垃圾测试。 6 前边的规则尽量都写成 lint

lifcc

@mylifcc · 2026-09-16

如果你在用 PostgreSQL，建议先收藏这个开源小工具。 很多人给 AI Agent（Cursor / Claude）配工具时，最缺的就是“数据库实时体检”能力。 刚发现一个叫 pgbot 的开源工具，定位是“Postgres Intelligence for AI agents & apps”🧵👇

赵纯想

@chunxiangai · 2026-09-15

不要再用 “弹窗”、“下拉菜单”、“闪光加载”、“菜单栏”来和 AI 交流 UIUX 开发了。有时候，命名正确，交流更顺畅，更容易一发命中。你会第一时间看到更符合心意的东西。这个网站可以帮助你学习这些经典组件的名称。 https://component.gallery/

碗

@tcdwww · 2026-09-15

没错，这只碗还在找工作。 目前意向是擅长前端的全栈工程师、前端工程师。 在自学 Agent 开发，已经有一个在自己 Telegram 群组跑起来的群宠 Bot「塑料碗」。 意向 base 北京，其次是上海/杭州。 在线脱敏版简历可以戳 -> https://resume.tcdw.net 欢迎通过在线脱敏版简历里面的 email 联系我。

valzav

@valzav · 2026-09-19

I've open-sourced Valcraft, my set of skills for developing software with AI agents. It helps take work from specifications to verified code and reduces manual coordination between agents. A little background. Complex projects need git, meaningful commits, branches, and pull requests. They also need clear context: code, tests, requirements, plans, decisions, and lessons from mistakes. Both agents and people should be able to tell what to do, in what order, and where to stop. Spec-driven development (SDD) gives that work a structure: write down the requirements and definition of done, plan the work, implement, and verify the result. I spent a lot of time working with several popular SDD frameworks for agents. They helped structure the work, but progress on my projects was slow. The agents and I kept having to work out which information was current. The frameworks' internal files ended up in git, and all that process detail made changes to the code harder to see. Architecture descriptions and project documentation were duplicated in framework directories. We had to figure out which document was the source of truth. Small tasks routinely bypassed SDD, so the process didn't account for all the work. Context quickly filled up with the frameworks' internal data. I once measured token use with one of them: 20% went to implementing and reviewing code, and 80% to running the SDD process. I also had to keep approving transitions: give an assignment, then approve the specs; the agent runs a review, then approve the fixes; time to merge, approve again. Then I had an idea: make specifications, plans, and decisions part of the project itself, without duplicating them in a framework's internal directory. And simplify the process so agents spend fewer resources maintaining it. I tried the approach on my own projects, and it made the work easier. I formalized the process and packaged it as a plugin with skills for Claude Code, Codex, OpenCode, and Cursor. You can add Valcraft at the start of a project or while development is already underway. Specifications, plans, and decisions live alongside the code. Requirement IDs link them to tasks, commits, and pull requests, so you can trace why a change was made and how it was checked. Later I added Foreman, the coordinator. It dispatches agents and reviewers, reads their reports, and chooses the next step. In unattended mode, it handles routine transitions itself. You still resolve unclear requirements and confirm that a feature is complete. Each new stage starts with an agent that has fresh context and reads the project files it needs. Foreman only reads the parts of reports it needs for the next decision. Another useful piece is independent review. If you use Herdr, the agent writing the code and the agent reviewing it run in different coding-agent applications: Claude Code checks Codex's work, or vice versa. Reviews cover specs and code. Findings need evidence; bugs in code behavior need to be reproduced. After fixes, the reviewer rechecks the issues. Foreman brings unresolved material findings to you. Before merging, Land checks that the current code has passed review. In the next few days, I'll post a video of Valcraft building a small game in one run, from the assignment to a verified result. I'll show how it works in practice.

陈成

@chenchengpro · 2026-09-16

Claude Code 团队自己，已经有 70~80% 的工作不在终端里做了。 看完 Thariq、Sid、Robert 三个人的 22 分钟对谈，记了几条。 1. 大部分活在 Slack 里的 Claude Tag 上干。TUI 和桌面端只有两种时候才开，精修某个东西，或者"想微观管理我的那些 Claude"。给的也不再是任务，是目标。 2. 以前底层技术的保质期以年计，现在是两个月。Sonnet 3.5 时代模型给它五件事只做三件就放弃，于是加了 to-do list，一下就好了。一年后这个功能没了，因为不需要了。Sid 的结论是对自己造的东西不要有感情。 3. harness 里大部分功能，说白了是在给当前模型的失败模式打补丁。模型变强就主动删。但任务尺度同时在变大，又得造形态完全不同的新工具。这两句得一起记，只记前一句就是为删而删。 4. AskUserQuestion 这个工具磨了很久才让模型学会调用。结果作者现在自己都不怎么用了，直接让 Claude 出一个带 mockup 的 artifact 来问他问题。 5. Code review 变了。人类 reviewer 挑三个小 nitpick，其实是在证明"我读了"。这活交给 Claude。人只管 Claude 不知道的事，这个 API 为什么长这样，服务边界为什么画在这。 6. workflows 是从 code review 长出来的。fan out 找 bug，每个 bug 再从几个角度对抗性验证，过滤掉误报只留真的。Robert 信任 workflows 的理由很简单，编排层是代码，for 循环不会漏掉任何一项。 7. Claude Tag 第一次把界面和 transcript 彻底分开。Slack 里看到的每条消息都是它主动调工具发的，内心独白看不到。他们一开始很慌，后来发现不盯着也能拿到好结果，才意识到模型真的到这一步了。 8. 怀念什么？Sid 怀念性能优化，"现在 Claude 比我强得多"。Robert 曾经花一整天手写 CSS 复刻 Mac OS 10.4 的 Aqua 按钮，叠了好几层 radial gradient。他说再也不会手工做这种事了。听着有点唏嘘。