FantasyAILab

Share And Build.

[meng shao @shao__meng]

AI Engineering Skills Map 系列之「软件工程基础」

吴恩达老师的 AI 工程技能图谱第二篇详细展开：
1. 构建与部署 AI 应用
2. 软件工程基础（本文主题）
3. 使用 Coding Agent
4. 塑造构建方向

吴恩达老师认为：Agentic Coding 降低了"写代码"的门槛，但抬高了"懂软件"的价值。 会用 AI 写代码 ≠ 会做软件工程；真正的竞争力在于你能否驾驭 Agent 做出正确的工程权衡。

论证链条非常清晰
现象：编程 Agent 可以替你写所有代码，语法记忆类知识正在贬值。
问题：纯 "vibe coding" 的新手能做出简单应用，但 Agent 会在延迟、可用性、一致性、可靠性、可维护性、简洁性、成本等维度上做出糟糕的默认权衡——而开发者根本不知道这些权衡存在，自然无从纠偏。
结论：软件工程基础并没有被取代，只是从"手写能力"转变为"决策与驾驭能力"——你得知道有哪些权衡，才能引导 Agent 做出符合你���用场景的选择。

# 五大核心能力

1. 构建全栈应用
变化：Agent 让前端、移动端等"专才"可以快速扩展为"全栈通才"。
不变：你仍需理解 UI 组件、缓存、页面渲染、API 设计、认证、状态/会话管理、异步处理、数据持久化、测试、安全、可访问性等关键概念——否则你无法判断 Agent 生成的方案是否合理。
本质：Agent 补的是"熟练度"，补不了"判断力"。

2. 数据管理（全文最重点论述的部分）
单独强调数据，原因有三：
数据是地基，且最难改：代码可以重构，数据架构一旦定型，迁移成本极高（即使有 Agent 辅助）。
数据决策高度依赖人类上下文：存什么、存多久、选什么存储模型（��系型/文档/KV/图）、事务与并发、数据生命周期——这些都需要业务理解。
对 AI 应用有双重重要性：你的 AI 系统直接从数据源获取上下文，数据架构错了，AI "不知道自己不知道什么"，错误会被静默放大。
前瞻性提醒："为 Agent 而建的数据基础设施"（区别于为人类/传统软件而建）是快速演进的新领域，最佳实践需要持续更新。

3. 系统架构设计
架构 = 在理解全栈组件 + 数据之后，把它们组装起来的决策：前后端边界、系统拆分、状态放置、单体 vs 微服务、技术栈选型。
关键洞察：正确的架构是移动靶。原型期、首个生产系统、规模化阶段，各阶段的最优架构不同。架构能力 = 随阶段演进架构、持续做出更好权衡的能力。
这需要"技术深度 × 业务上下文"的双重知识——恰恰�� Agent 最缺的部分。

4. 安全与可靠性
可靠性：测试策略（单测/集测的比例、框架、覆盖率）、面向失败设计（限流处理、优雅降级、缩小爆炸半径）。
安全："Shift Left"——安全前置到开发生命周期早期。趋势是所有开发者都在变成"半个安全工程师"。
辩证看待 AI 安全工具：AI 可以扫漏洞、查供应链注入、审云配置，但用好这些工具本身需要安全知识——工具放大能力，不替代能力。

5. 规模化与生产运维
覆盖完整 SDLC：部署环境、发布策略、CI/CD、IaaS。
生产运维三件套：可观测性、告警、事故管理。
规模化手段：理解真实负载、水平扩容、负载均衡、数据层扩展（分片、索引、复制）。
加上"软"工程实践：版本控制、Code Review、依赖维护、技术债管理——这些决定了系统能否长期演进。

吴恩达老师的深层思想表达
· 知识价值从"记忆型"迁移到"判断型/决策型"
· Agent 优化的是"能跑"，不是"适合你的场景"；上下文只能由人提供
· AI 系统的错误是静默的，比传统软件的 bug 更危险
· 工程能力的核心不是"选对一次"，而是"持续演进"
· AI 时代的工程师画像是"广度扩张 + 决策深化"

给咱们的启发和建议
· 用 Agent 写代码，但用自己的大脑做决策：每个 Agent 生成的方案，追问自己"它在延迟/成本/一致性上做了什么取舍？"
· 优先投资数据与架构知识：这是最不可逆、最依赖人类上下文的两个领域。
· 把安全和测试前置：让 AI 安全扫描工具进入你的工作流，但先建立基本的安全认知框架。
· 按阶段演进架构：原型期容忍简陋，但要有意识地规划向生产架构的迁移路径。

[宝玉 @dotey]

Claude 新的一篇博文《How Warp builds self-improving agents on Claude》 https://t.co/CsyjaGY8TC ，看了后还是挺有收获，它解决的是 Skill 的进化问题。

这个问题我以前也研究过，我写了一个反编译 JS 代码的 Skill（https://t.co/y6kA8TDnZ3），每次 Agent 反编译的时候遇到新的场景解决了就自己更新自己的 Skill，效果还不错，能一直优化，��是 Skill 文件越来越大。

我还研究过写作的自我进化 Skill，那个就一言难尽，因为它其实没有自己统一的标准，经常负优化，越写越糟糕。

说回来 Warp 这个，Warp 是一个挺有名的终端工具，内部尝试借助 AI 做 Code Review。一开始让 Agent review 代码，效果并不理想，主要问题体���在 Agent 不了解你的项目，不知道你的团队规范，不知道历史经验教训，就算你指出来问题它下次还记不住。简单来说就是没有记忆。

初期他们采取了很多补救措施：
- 手动根据失败案例改系统提示词
- 完善项目的 AGENTS.md 文件（有意思的是这篇文章是 Claude 发的，但是用的是 AGENTS.md 而不是 CLAUDE.md，我记得 Claude 默认不支持 AGENTS.md 的😅）

但效果并不理想，一方面它依赖于人主动去做，成本较高；另一方面团队成员在 Code Review 时人工在 PR 写的高质量评论完全没用上。

所以他们搞了个解决方案，一个基础 Skill 负责做代码审查，一个改进 Skill 负责定期收集人类工程师在代码审查时的评论，尤其是对 Agent 审查结果的评论，根据人类工程师的评论去更新代码审查的 Skill。

换句话说，它不是依赖于模型自己去改进自己，而是 Agent 根据人类对模型结果的标���（人类对代码审查的评论），去改进技能。

只不过它把这个事做的摩擦力极低，不需要人手工去收集整理评论，不需要填写调查问卷，人只要自然的去代码下写评论，后面的事情都是 Agent 自动完成。

这可能正是 Agent 的最佳实践方案之一：人负责高纬度的标注、评论、反馈这些事情，Agent 去做执行的工作，Agent 根据人类的反馈去改进 Skill。

除此之外，他们还总结了一些最佳实践：

1. 写原则，不要写死规则。

编写 skill 时，要像在指导一个聪明人，而不是在给计算机编程。在 Skill 中写“寻找重复代码”，比列出详尽的变量命名规则更有效。

2. 解释为什么。
说明规则背后的理由，能让智能体针对问题进行推理，而不是机械执行僵化指令，也因此更容易举一反三。

3. 让反馈没有摩擦毫不费力。
在人们原本工作的地方收集反馈，例如直接评论 PR 或 issue。同时让收集过程自动发生，不要增加额外的提交步骤。低摩擦才能让信号持续流动。如果反馈太麻烦，你就收不到反馈，也就无法改进 Skill。

4. 保持 Skill 精简，并使用渐进式披露。
优秀的 skill 文件不会很庞大；它会引用资源文件和脚本，而不是一次性把所有内容都塞进上下文。

5. 反馈质量大于数量，但数量也有帮助。

一位资深工程师给出的少量、详细且与领域相关的反馈，可能比大量草率反馈更有价值，因为简单的赞成／反对并不能说明“为什么”。

即使样本量相对较小，只要反馈来自掌握领域知识的人，而且足够详细，你也能得到非常好的信号——这些知识是智能体通过其他方式根本无法获得的。话虽如此，优质信号的语料越多，效果越好。

6. 做���改进 Skill 的 Skill，可以用来改进其他 Skill。

把改进 Skill（也就是前面提到的一个代码审查 Skill 一个改进 Skill）做好，收益不只限于眼前这套 Agent 循环，因为改进 Skill 在不同用例之间具有很高的复用性。除了领域专用知识这一部分，它其实是一套相当通用、可复用的机制。代码审查 Agent 的改进 skill，也可以应用到其他 Skill 的改进上。

可能有人会担心：如果反馈本身是错的呢？

Warp 的做法是永远不让 Agent 盲目接受反馈。给它足够的上下文来做基本的合理性检查，限制谁的反馈有权影响技能更新（不是所有人的意见都同等重要），最后始终保留人在循环中审核改动。

对于那些有明确标准答案的领域，比如代码是否通过了测试、部署是否成功，可以先建一个验证基准，让 Agent 自己对着基准跑。没有标准答案的领域，比如代码风格、文档质量，就靠领域专家的判断，不要开放给所有人随意反馈。

[FantasyAILab @firetank618]

@lifesinger 国内厂商的国版codex已准备好

[FantasyAILab @firetank618]

#范特西Day LLM Wiki的思路确实不错，Agent自进化本质不也是LLM操作一坨子MD来进行index和分层归档吗

[FantasyAILab @firetank618]

#范特西Day1 脑海里琢磨fantasyAI Lab有2个月了，重构了3��结构、方向和所谓的运营模式，但是一直还没想到AI Lab怎么解决Lab问题，怎么做vibe labing而不是吹水，毕竟现在没有人类爱看文章，大家都想证明自己懂AI，怎么帮助实现这个过程落地和Lab的研究有所得一定是矛盾的吗🤡

[Easycompany @Easycompany333]

Google 出品，8分钟手把手带你做一个最小的Agent loop，可能是对于Loop最快捷的理解。

其实我个人写的文章也好，实际使用也好，真正从理解角度来说，不复杂，就像理解Skill一样，需求的就是对于文档和文档内容的管理，而不再是提示词的管理

但是Skill能写好，也不容易

同理，loop能使用好，也不是理解的那么容易

最重要的还是要先用起来

实践是检验真理的唯一标准

[Luna @LunaAI519]

此文喂给 codex 或者 cc，小白直接起飞！

[小盖 @xiaogaifun]

字节对大厂 AI Coding 的反思，好真实。

字节技术副总裁洪定坤的分享，我来回看了好几遍，很有启发。

字节在 AI Coding 方面的实践还是很有代表性的，推荐所有做研发的同学都可以看看。应该会感同身受。

我看完记了一整页笔记，分享给大家。

我甚至觉得可以把这个分享理解为字节在 AI Coding 上的一些真实反思。

根据自己的理解，我把这个分享里对我有启发的几个判断展开来聊一聊。

其中会夹杂很多我自己的感触，想看原文的可以直接去找演讲全文。

反思一：AI 代码贡献率不该是 KPI

AI Coding 基本上都已经逐步进入了各个公司的生产流程。

很多人都在说自己的业务有 90% 的代码是 AI 生成的，乍���听，感觉很恐怖。

但其实，AI 对研发的提效没有外界想象的那么高。

洪定坤举了 TRAE 团队的例子。TRAE 本身就是做 AI 工具的，所以这个团队对 AI Coding 的采用非常积极。

过去半年里，他们有 94% 的代码都是 AI 贡献的。但人均需求吞吐率只提升了 60%，也就是之前的 1.6 倍。

这就有疑惑了，AI 写代码的速度至少是人的 10 倍以上，如果 90% 以上的代码都是 AI 产出的，效率至少应该提升 5 倍或者 10 倍吧？为什么只提高了 1.6 倍？

字节得出来的结论是，单一的指标，比如 AI 代码占比，根本没有办法代表真实的生产力。

如果把 AI 代码贡献率当成 KPI，结果就是大家都去优化 AI 的生成量，而不是优化交付能力。

看起来 AI 用了很多，但系统的效率并没有真正变好。

那为什么 90% 的代码都是 AI 写的，人效才提了 1.6 倍？一个很重要的原因是，写代码只是整个研发流程的一个环节。

写之前要理解需求、写 Spec，写完之后要验证功能、提交发布，这些环节如果还是传统方式，光把写代码加速了，整体效率提不上去。

洪定坤把字节在这方面的尝试叫做系统化的 AI Development，核心意思就是 AI 不能只管写代码，得让它进入更多的研发环节，整条链路��跑通，效率才能真正上来。

前两天出去的时候还跟别人争论这件事。现在还有不少公司在追踪员工到底用了多少 Token，说白了，这是在追踪过程。

更应该关注的是，用了这个工具之后，从结果层面去看，交付到底有没有变得更快、更可靠。

一个团队天天说自己 AI 工具用得贼溜，消耗了多少 Token，但没有什么有效的产出，那这到底是好事还是坏事。我觉得这是一个值得每个管理者思考的新问题。

反思二：功能正确≠工程可用

Vibe Coding 的理想状态是就像聊天一样，用自然语言表达自己的需求，最后做出来想要的产品。

如果哪里不对，再用自然语言和 AI 沟通，让它修改。这是过去一年 Vibe Coding 风靡的思路。

对于不太复杂的应用，这种方式完全没问题。我自己做的一些项目基本上就是这个流程跑下来的。

但只要是做生产级的软件，无论公司大小，流程肯定不是这样。

因为公司里必然有��代码，有一套约��。怎么复用已有的组件，安全和权限怎么处理，性能怎么保证，还有兼容性、可维护性。

正经写过工程代码的人都清楚，Vibe Coding 描述的那个状态是比较理想化的，更适合做小项目和验证想法。

真正的程序员虽然也在 Vibe Coding，但流程跟理想状态不一样。

字节内部做了一个实验来验证这个判断：三个模型，三个 Agent 框架，两两组合成 9 种方案，针对同一个需求，每组跑 100 次，总共 900 次。

结果发现，AI 在功能正确率上表现还不错，所有组合都超过了 80%，也就是说，AI 把功能写对的能力已经过了及格线。

但无论哪个组合，生成代码的工程质量都不太好。比如 UI 不对，没有复用组件，性能有问题，结构不符合规范。

这些问题大家在用 AI 写代码的时候应该都碰到过。

现在所有上了牌桌的 Coding 模型，都已经过了 Opus 4.6 这个级别的临界点，模型可以自主写代码了。

这个时候影响 AI Coding 成败的绝对不是��模型，而是裸模型加上 Harness 的能力。

这个判断本身不算新鲜。

但我最受触动的是字节对 Harness 的理解。

他们的反思是，整个行业好像还是把 Harness 等同于 Agent 框架，诸如用 single agent 还是 multi agent，包含哪些角色，角色之间怎么配合。

这些当然重要，但字节在实践中发现，真正决定 AI Coding 能不能落地的，反而是更基础、更工程化的东西。

洪定坤把它叫做基建。

比如上下文工程有没有做好，架构的约束够不够清晰，团队的知识能不能有效沉淀下来，过去的技术债有没有梳理清楚。

这些看起来不那么性感的工作，反而直接影响 AI Coding 的效果。

实验数据也验证了这一点。同样的模型和框架组合，把这些基建结合进去之后，功能正确率直接从 80% 提升到了接近 90%，工程质量得分，也从之前 40 到 60 分的不及格水平，普遍提升到了 80 分左右。

��建做不好的话，可能的后果是，Vibe Coding 感觉快了，但实际整体可能更慢。工程的债，迟���得还。

反思三：代码门槛下降之后，团队怎么协同

洪定坤分享里有一个例子让我印象很深刻。

产品经理有个需求，发现还得等研发排期，就说那我自己来吧，用 AI 三下五除二就把功能给实现了。

确实这个功能不复杂。做完之后产品经理把代码给到研发，说我已经把代码写完了，现在你只需要帮忙把功能上线就行。

研发一看，不行。你这代码能跑，但不符合上线的规范，有权限问题、安全问题。

产品经理就很委屈，你们没时间做这个需求，现在我都做完了又不让上线。可研发看到的其实是代码质量的问题。

所以这里面就有一个需要所有人正视的事情，虽然代码的生成门槛虽然下降了，这并不代表系统的复杂度也下降了。

真实的业务系统里，代码要放到已有的架构里，要跟已有的模块配合，还要考虑各种各样的问题。

绝对不是谁写出来就能���接上线的。不然肯定会出问题。

怎么让不同角色的人用同一套工具和规范做出符合要求的代码，这是接下来大家需要去解决的。

字节的思路是在内部尝试工具化。比如把内部实践直接产品化，沉淀到 TRAE 里面，开放给所有人。

其实说白了就是工具化。

我看朋友圈有好多大佬也都在转这篇文章，应该还是有挺多共鸣的。

我感觉这一次分享多少也是一些拨乱反正吧。因为过去一段时间确实有很多听起来很离谱的言论，有些人会疯狂地炫耀自己使用了多少 Token，会认为这就代表着 AI Native......

强烈推荐大家看看原文。字节跳动的公众号就有。

[Xudong Han @Xudong07452910]

🛠️ 强烈推荐的开源项目：Trellis —— 让你的 AI Coding Agent 拥有团队级工程规范的开源 Harness

Trellis 是我一直在使用的 AI 编码工程框架，被称为“The best agent harness”。

它通过将项目规范、任务上下文和记忆持久化到代码仓库，让 AI Agent（如 Claude Code、Codex、Hermes Agent 等）不再每次从零开始，而是拥有团队级的工程标准和跨平台一致性，大幅��升开发效率和代码质量。

具体来说：

很多人觉得 AI 编码 Agent 越写越不靠谱，第一反应是换模型、堆提示词、加更长的上下文。但问题很多时候不在模型，而在它每次进项目时都是“空着脑子”进场：

项目结构不知道，命名规范不知道，技术选型不知道，上次做到哪也不知道。

Trellis 做的事，就是给 AI 编码 Agent 装上一套项目级工程记忆。

它会在你的代码库里建立一个 .trellis/ 目录，把项目规范、任务 PRD、实现上下文、审查记录、会话日志都沉淀下来，并跟代码一起进入版本管理。

也就是说，你不是每次重新教 AI 怎么写这个项目，而是让它每次开工前先读项目自己的“工程手册”。

它最有价值的地方不是单纯塞上下文，而是把 AI 编码流程变成一套标准工作流：

1. Plan：先把需求问清楚
2. Implement：按 PRD 和项目规范写代码
3. Verify：对照 lint、type check、test 和 spec 自查
4. Finish：把这次踩过的坑和新规则写回项目记忆

这就很像把一个“聪明但每天失忆的临时工”，慢慢训练成一个“知道项目规矩、能接着上次继续干活的团队成员”。

更关键的是，Trellis 不绑死工具。它支持 Claude Code、Codex、Cursor、OpenCode、Gemini CLI、GitHub Copilot 等 14 个 AI 编码平台。团队里一个人沉淀的规范，全队的 AI 都能继承。

✨ 核心特性：
1. 自动注入规范：.trellis/spec/ 中编写一次，AI 每次会话自动加载
2. 任务中心工作流：.trellis/tasks/ 存放 PRD、实现上下文、审查记录
3. 项目记忆：.trellis/workspace/ 记录上一次会话状态
4. 团队共享标准：规范随代码版本控制，团队共用

目前已获 9.7k+ stars ⭐，有中英文文档，社区活跃。特别适合个人开发者、团队工程师和重度使用 AI 编码工具的用户。

也推荐一下项目的负责人之一：卡牌大师崔斯特 @cuisitekp。

https://t.co/xLoN7fOqOU

#AIAgent #ClaudeCode #AgentHarness #AI工具 #开源项目 #Codex

[Jealousy 尼卡 @eastweb3eth]

中文 Vibe Coding 从入门到精通教程

我发现越来越多朋友开始 Vibe Coding，由于很多朋友都没有任何代码基础，也不知道如何开始。现在我来给大家推荐一个：【中文 Vibe Coding 从入门到精通教程】。

仓库：https://t.co/I3mLy5VtnF 12.8K星星

这个教程好的地方就是原生中文，大家学习起来没有任何语言阻碍。

这个教程手把手交给你从想法到产品的 AI 结对编程工作流标准：Prompt + Skill + Context + Quality Gate + 工程闭环。

最后感谢开源的作者：@shao__meng @geekbb @xDinoDeer @Pluvio9yte @0XBard_thomas ，排名不分先后。

我是尼卡，平时会持续分享 AI、美股、Web3 相关有用又有趣的工具和项目，感兴趣的话欢迎关注，下次见～

[yetone @yetone]

由于这篇文章太伟大了，所以我把它变成了一个 Agent Skill。

大家可以使用自己的 Coding Agent 安装一下这个 Skill，这样就可以用「最佳实践」来轻松地重构或者开发一个既容易跨平台、又极其接近 Native 性能的桌面端应用。

https://t.co/VdAhLhoSQE

[币世王 🦅 @0xKingsKuan]

还在用剪映一帧帧手剪视频？太落后了！

Codex 装上 HyperFrames 插件，直接写代码生成 MP4！

普通人也能 10倍速批量做短视频号，HTML 秒变专业视频！

安装→下指令→自动出片，一人就是MCN

用了就回不去了 😭

[摆烂程序媛 @wanerfu]

OpenClaw 现在可以抓取任何网站而不被屏蔽——零机器人检测，原生绕过 Cloudflare，比 BeautifulSoup 快 774 倍。

无需维护选择器。无需变通方案。只需数据。

这是不公平的优势，而且完全开源。
https://t.co/4r4Jg23jal

[杂学大师✨ @Techbruneth]

面试时：

'你为什么要离职？'

大多数候选人说：'我想寻求更多成长机会和更好的公司文化。'

获胜答案是：

[阿川 | AI thinking @AI_jacksaku]

刚发现一个疯狂的开源项目：Claude-Code-Game-Studios。

11,574 stars，今天涨了1,107星。

它是什么？

一个完全由AI Agent组成的游戏开发工作室。

听起来很科幻对吧？
但你知道这解决了多大的痛点吗？
以前做游戏，需要程序员、美术、策划、测试...
一个小团队都要5-10人。

现在，这个项目用49个AI Agent，
分工协作，各负责一个环节：
有的写代码，有的画素材，有的测bug，有的优化性能。
72个工作流技能，覆盖完整开发流程。

更狠的是，这些Agent用Claude Code驱动，
能自主决策、自我纠错、协��工作。

我翻了下他们的demo游戏，
虽然还很简单，但完整度惊人——
从概念到可玩版本，全Agent完成。

这就是游戏开发的未来：
一个"人"的工作室。

AI做游戏，你觉得能出大作吗？👇

🔗 https://t.co/kpfEb8XXMa

[FantasyAILab @firetank618]

昨晚更新的GLM-5.1今早迫不及待想看下效果，给了一个复杂的Rust、Openclaw的端侧任务后我就出门了，回来发现自己跑了一个半小时居然任务一次过了，把龙虾用Tauri打包构建了一个App，可怕的是体积只有几M，AI orchestration时代越来越近了（转行吧

[Viking @vikingmute]

这个 claude code 的 skill 项目大家可以关注一下
https://t.co/6GNxYDGvqP

号称可以一个命令复制你要参考的网站的样式，安装完后运行 /clone-website 就可以完成复制

看了一下原理，通过 Chrome MCP 自动完成以下工作：
1 分析网站 截图、提取设计 token，交互行为
2 生成详细的组件规范
3 使用并行 sub agents 处理不同部分，自动重建像素级的克隆版本
4 最后自动合并代码，并进行视觉差异 QA

作者提供了 demo，效果确实不错，我还没有尝试，大家想直接一键精确获取参考网站的模版可以试试看

[陈成 @chenchengpro]

大多数人用 AI 写代码，还在一条条手敲 prompt。

真正的差距不在于谁用了更好的模型，而在于谁把自己的工程经验编码成了可复用的流程模块。

Matt Pocock（TypeScript 圈知名工程师）把他每天在用的 5 个 agent skill 全部开源了：

→ /grill-me — 在你动手写任何东西之前，对你的方案发起连续追问，直到把每个决策分支都逼出来。他自己被问了 24 个问题，坐在那写了一小时 PRD。

→ /write-a-prd — 通过互动访谈 + 读你的代码库，生成一份完整需求文档，自动以 GitHub Issue 归档。

→ /prd-to-issues — 把 PRD 按「垂直切片」拆成一个个独立可认领的 Issue，开箱即用。

→ /tdd — 经典红-绿-重构循环，每次做一个切片，逼 Agent 先写测试再实现。

→ /improve-my-codebase — 扫描代码库，找架构改进点，重点是加深"浅层模块"和提升可测试性。

三天前刚开源，已经 1.2k star。

这背后的本质是：会 prompt 的人很多，能把经验系统化的人很少。 Skill 就是把你作为工程师的判断力和流程，变成 Agent 可以反复执行的操作合约。

你写给 Agent 的 skill，就是你在这个时代留下的工程资产。

https://t.co/PzelKeITpK

[陈成 @chenchengpro]

OpenAI 公开了他们用 Codex 维护 Agents SDK 的完整方案，值得每个 AI agent 用户学一遍。

核心结构只有四层：

1. AGENTS.md — 强制触发规则，用 if/then 写清楚什么情况必须调哪个 workflow
2. .agents/skills/ — 封装具体工作流，每个 skill 一件事、一个触发条件、一个输出
3. scripts/ — 固定顺序的 shell 操作放这里，不让模型每次重新猜
4. Codex GitHub Action — 本地稳定了就搬进 CI，逻辑完全复用

还有一个容易忽视的细节：skill 里 description 字段是路由信号，不是注释。写模糊了 agent 就不知道该用哪个 skill。他们的建议是——路由不准先改 description，别加代码。

把这套思路推广开来：任何项目，只要把工程规范显式编码进仓库，agent 的行为就会稳定得多。

示例仓库：https://t.co/OhaQYxkm93
原文：https://t.co/xomJVkMQra

[Frank Wang 玉伯 @lifesinger]

YouMind 从去年开始，对所有入职员工，都可报销 AI 订阅费。可以是自己日常使用的 AI 产品，也可以是做产品分析时产生的 AI 费用。一个月的报销费，从几十到上千刀都可以。

同时，我们也不会去评估 tokens 消耗。想消耗多的，就多消耗。想少花 tokens 多用人脑的，就可以少花。

让人使用 AI 无负担，同时尊重每个人本身的能力。相信 人 + AI 会远大于 AI，不守旧，也不过于激进，是我们的心态。

持续招聘以下人才：
1. 优秀的全球化 CMO 联创，虚位以待 + 期待
2. 类似 Peak 的 AI 科学家，让 YouMind 有机会超越 Manus
3. 优秀的 Agent 全干工程师，来 YouMind，不后悔

期待我们的相遇。能一起让这个世界有所不同，顺便赚大钱。

有兴趣者，可 X 私信我，或邮件：[email protected]