Imchao9

分享个人 AI 实战干货

[数字生命卡兹克 @Khazix0918]

被很多专业者骂了，但是在折腾了3天以后，AIHOT最终还是重写完然后上线了。。。我觉得还是可以分享一下我全部跟AI协同的流程，万一对其他人有用呢（当然我就是个纯外行，仅供参考）：

1. 使用Claude Opus 5.5和GPT-6 Astra并行对旧项目进行蒸馏，并且设计交流包。要求：架构分离，为多Agent并行开发而设计，保留所有功能和容易踩坑的细节。

2. 使用Claude Fable 5.1对两个模型生产的功能文档、交接包和旧代码库进行全面对照，寻找不合理和遗漏的地方进行完善。

3. 使用Claude Opus 5.5在不看任何旧代码的情况下，根据最终的功能文档、交接包、线上网站的端到端测试，进行全方位的重写（大概写了12个小时）。

4. 使用Claude Fable 5.1和GPT-6 Astra并行审查新写完的项目，将其与旧代码库的所有细节进行逐行审计，看看是否有功能和细节遗漏，在用户体验层面，能否完美还原，最终产出两份审计报告。

5. 使用Claude Opus 5.5根据审计报告，进行优化开发，开发完成以后，清空所有上下文，自己再并行N个子Agent，以功能模块化的方式，跟旧代码库进行对比，看是否遗漏功能和逻辑细节（无视代码实现，只看功能和逻辑细节）。

6. 使用Claude Fable 5.1和GPT-6 Astra并行审查所有可能的BUG和漏洞，继续Opus 5.5优化。

7. 使用Opus 5.5优化所有前端UI，进行控件组件化统一，部分UI界面全面重设计，加了一部分Opus 5.5擅长的JS+Canvas动效，例如关于页和更新页。

8. 导出旧项目所有数据库，进行线上服务器彩排，6小时的影子系统并行，过程中实时监控，使用Claude Opus 5.5自动化并行修复过程中出现的所有问题。

9. 使用GPT-6 Astra进行全面的端到端测试。

10.无缝切换上线。

11. 使用GPT-6 Astra根据真实数据，全方位优化缓存、CDN、页面大小等问题，提升全站性能。

12.监控问题，不断优化。

以上，大概就是一个纯外行者的“重写”的经验，虽然AIHOT这个项目很小，但是我自己干的很开心。希望能对大家有一点点的启发。

[Imchao9 @imchao9]

@alin_zone JWNITF 大家随便用

[Imchao9 @imchao9]

@vista8 乔木大佬为啥我这边不行

[Imchao9 @imchao9]

@oasisfeng JWNITF

[Imchao9 @imchao9]

@jarvis11x JWNITF

[Imchao9 @imchao9]

@rwayne Muse邀请码：JWNITF

[Imchao9 @imchao9]

@0xlangeai 救救孩子吧！谢谢

[Imchao9 @imchao9]

@jinglian

[LinearUncle @LinearUncle]

这周帮其他团队电话面试了几个应聘垂直业务 agent 研发的候选人，基本上我开头一个问题就能初筛掉 90% 的面试者：

/goal 命令是如何实现的？

真正做过 harness 的人才知道 goal 有多难搞：完成判断、验收标准、状态持久化、异常兜底、预算控制、上下文压缩不丢任务、缓存命中不被打乱。。。

[旺旺 @TiagerBao]

AI 写代码审查，最怕的不是没发现问题，而是发现几个问题就以为审查结束了。

Super Hermes 是给 Hermes Agent 用的一组 Skills，核心思路是：先生成适合当前任务的分析方法，再执行，最后报告发现了什么、没覆盖什么。

它提供了 5 个主要技能：

• /prism-scan：针对当前代码生成分析视角，执行后输出问题和限制。

• /prism-full：多轮分析，后续轮次会主动攻击前面的结论。

• /prism-3way：从 WHERE、WHEN、WHY 三个方向分析，再交叉汇总。

• /prism-discover：先梳理一个项目可能需要分析的领域。

• /prism-reflect：除了发现问题，还会报告这次分析遗漏了什么。

README 给了一个实际对比：同一份代码、同一个模型，普通分析输出 339 词、发现 7 个问题；使用 prism 后输出 1485 词、发现 11 个问题，并增加了结构性权衡和盲区报告。成本都约 $0.05。

项目还附带 7 个预设分析棱镜，覆盖错误恢复、结构性权衡、性能优化、身份一致性、信息丢失、假设反转和时间演化。

更有意思的是，它会把分析限制写入 .prism-history.md。下一次分析同一项目时，可以参考之前遗漏的角度，调整分析方法。

不过它目前主要是单文件分析，质量依赖模型，也没有标准化外部 benchmark。README 中的分数来自 AI 评估实验，不能直接当成客观性能排名。

你们觉得 AI 做代码审查，多轮审查更重要，还是让它先明确自己的盲区更重要？

github：https://t.co/n1SnKhjCxx

#AI #HermesAgent #ClaudeCode #OpenSource

[meng shao @shao__meng]

The Pragmatic Engineer 对话 264K🌟 Skills 作者 Matt Pocock，96 分钟谈透人机分工：AI 已吃掉战术编程，战略层是工程师最后的护城河。

从 grill me 拷问式对齐，到 spec→tickets 会话切分，再到 wayfinder 地图式规划；这套工作流的答案，藏在 25 年前的软件工程经典里。 https://t.co/KNgGkrASUD

[南晚Nanwan @snwiki238337]

OpenAI发布了一套方法论，主要是关于如何评测skill效果的。对于做skill的人还是值得一看，而且github也找到一个理念很相近的skill评测器：agent-skills-eval，不过是个人维护的，非官方。

先定义成功，再写 skill。OpenAI把检查项分为了这四个点：
Outcome（任务完成没）、Process（调了预期的 skill/步骤没）、Style（产物符合团队规范没）、Efficiency（有没有瞎折腾/烧 token）。
没这个定义，skill 就只是个更长的 prompt；有了它，才能进版本管理 + 回归测试 + CI。
负样本比正样本更关键。博客里 test-04：用户只是想给现有项目"加 Tailwind"，skill 却新建了一整个 demo app。这种误触发比不触发更危险——因为它会动你的工作区。这是 agent 产品里最容易被忽略的验收口径。
Trace 是第一性证据。用 codex exec --json 抓 JSONL 事件流，确定性检查（跑没跑 npm install？package.json 生成没？）直接读事件，快、可解释、能进 CI；模型裁判（rubric grading）只做第二层"质量"补充，不替代规则。
小样本（10–20 条）起步：显式触发 / 隐式触发（不提 skill 名，靠 description 命中）/ 上下文触发 / 负向控制，各放几条。
它的主张我认为非常好：Agent 开发正从 prompt craft 走向 behavior engineering——skill 不该只是写给模型看的说明书，而该是可测、可评分、可回归的类似一个Agent的可复现测试的单元。

原文：https://t.co/RKI02HKVLK
仓库：https://t.co/RB9thRZOWA

[LimboAI @limbopeng]

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://t.co/9PFmgTv786

[RiverAi7z @RiverAi7z]

人类审阅代码的速度已经跟不上 AI 生成的速度了。
有些时候虽然代码能通过测试，但也可能存在大量不必要的抽象和难以维护的问题。

让一个 AI 审另一个 AI 因为提示词可能存在不确定性。

Earendil 这篇文章给出了一种解决方案 ⬇️
https://t.co/tgCWYAOzFS

[RiverAi7z @RiverAi7z]

@dongxi_nlp Pi 的作者引用了一篇关于 code review 的文章，它里面指出让人去 review 效率上不去，agent review 也不可靠，所以提出了一些新的方法，可以参考一下：

https://t.co/rLkOWO6r8a

[Johnny Nel | AI for Founders @johnnynelai]

GPT-5.6 / Codex lane map :

- Sol (medium): orchestrator, init, onboard, status, sync
- Terra (high): explore, spec, tasks, apply, fix-agent
- Astra (low): proposal, design, verify, judges, reviews
- Luna (high): archive

The keepable map is Sol orchestrate, Terra apply, Astra judge.
The next job should name the lane before copying the full yaml.

[AYi @AYi_AInotes]

在 Anthropic 刚刚结束的大会上，Google Cloud 架构师 Ivan Nardini 现场交出了一份震撼全场的答卷：
一个人、不预写一行代码，只用了短短 26 分钟，
从一张手绘草稿纸开始，把产品、设计、后端、安全审查、数据分析整整 5 个部门的活全部干完，
直接把一个带数据库和实时看板的真实 App 部署上线，台下几百号观众当场掏手机扫码打分。

这不是在聊天框里瞎吹水，而是一个人同时戴上 5 顶帽子，把一整条现代软件工程生命周期彻底走通：

1️⃣ 角色一：产品经理（手绘草图进终端）：
随手拍一张纸上的线框草图丢给 Claude，几分钟内直接生成可交互的 HTML 原型，甚至不需要懂 Git 就能直接开 PR；
2️⃣ 角色二：UI/UX 设计师（Plan Mode 架构锁定）：
绝不无脑写代码！先开规划模式，把页面结构、组件流向列清楚，挂载 Figma MCP 直接拉入设计资产，做成落地页与实时看板；
3️⃣ 角色三：软件工程师（3 个 Subagents 并行狂飙）：
告别单线等待！现场直接开 3 个子代理并发作战：
一个写后端 API，一个接入 Firestore 存原始数据，一个连通 BigQuery 做统计看板。每个子代理写完自己跑测试，人类只负责看绿灯；
4️⃣ 角色四：安全工程师（部署前致命门禁）：
执行内置的 `/security-review` 命令，系统现场扫出“缺少用户输入校验”，模型当场自己改代码、打补丁、收紧云端权限——“没有安全过线，谁也不准上线”；
5️⃣ 角色五：数据增长官（真实上线与即时洞察）：
容器一键推向 Cloud Run，观众扫码实时打分，数据安全地落在自己的 GCP 项目里，Claude 现场汇总提炼分析。

大家别只盯着26 分钟速成看热闹，这场演示真正拉开代差的核心只有一条：
差距从来不在 Prompt 提示词写得有多华丽，而在「工具链」的深度整合：
Figma MCP 解决设计导入、Developer Knowledge MCP 实时投喂最新官方文档（根本不需要你先成为 GCP 专家）、Subagents 解决并发隔离、以及把安全审查当成强制门禁。

当然，必须客观泼一盆冷水：
台上是一条设计好的 Happy Path（顺畅路径），真实业务里的复杂鉴权、计费多租户依然充满泥泞。
但这 26 分钟证明了一个残酷的现实：
从脑子里的一个想法，到全功能可点击交互的生产级 v0，
一个人 + 一套接好水管的 Agent，已经能把它活生生压缩到一次喝咖啡的会议时间。

旧时代的装配线散架了，
一个能用代码调动整支虚拟团队的超级单兵时代，在今天已经正式拉开帷幕。

[知识猫AI实验室 @GeekCatX]

GPT-6 Astra 出来有几天了，但是我发现很多人做出来的东西根本不是像之前官方演示那样。为什么会有这么大差距，我翻了一遍官方最佳实践使用文档，算是找到了答案，大概意思是说：
GPT-6 Astra的行为模式可以通过提示词模型来优化。
所以，为什么我们驾驭不了这头巨兽的原因就在这里了。大部分人给的命令都是一句话，最终的效果可想而知，全凭当时的算力上下文情况。

所以，我基于官方文档最佳实践做了一个gpt6-prompt-writer
我试了感觉相当可以，比如之前任务它时候拒绝输出或者不理想，用skill重写提示词后再去执行效果会很好多。

目前这个skill已经开源地址👇

[余温 @gkxspace]

卧槽，这套 GTM 能力太牛逼了，这是真正能帮你赚钱的东西啊，做产品和出海的兄弟们，必须狠狠收藏！！！

它把一整套 GTM 数据能力直接接进了 Codex、Claude：

1、Similarweb：网站流量、访问渠道、受众、排名、关键词，数据直接来自官方，不是爬虫或镜像站。
2、Ahrefs、Semrush、DataForSEO：SEO、外链、SERP、付费搜索和内容缺口。
3、X、Reddit、Instagram、YouTube、Pinterest：用户讨论、反对意见、内容趋势和创作者表现。
4、Apollo、WaveInflu：找公司、岗位联系人、达人和公开联系方式。
5、Oxylabs：查品牌在 ChatGPT、Gemini、Perplexity、Google AI Overview 里的可见度和引用来源。

以前做一次正经的市场研究，要开一堆数据平台，自己一点点分析。现在你只需要给 Agent 一个业务目标。

我最近想做一个 AI UGC 生成产品，于是拿它深度测了一把，效果真的惊呆了，它直接从 AIsa 调 Similarweb、Ahrefs、Semrush、DataForSEO……等十几个产品、40 个关键词，还有流量渠道、定价、招聘和用户评论。

你不需要研究每个平台怎么用。Agent 会根据任务自己找数据，最后直接给你竞品、需求、用户痛点、SEO 和 GEO 机会，还有具体的获客方向。

以前一个团队花大几万都很难集齐的专业能力，现在一个 Key 就能按需调用，丢给 Agent 几分钟全自动跑完，而且全是有据可查的真数据。

我把完整过程和最终报告都录进视频了，做产品、出海、SEO 或 GEO 的兄弟们，真的值得看看。

🔗：https://t.co/Dh1sChg3ki

[Matt Pocock @mattpocockuk]

What techniques do you use for making AI-authored PR's easier to review?

- I.e. use /show-me by @dexhorthy for easy-to-read diffs
- Describe the changes in pseudocode
- Mermaid diagrams
- Evidence of TDD

The wildest version of this I've heard is @dctanner's agent, who uses Playwright to record a video of the frontend feature working with text-to-speech over the top. So the agent literally talks you through its change.