返回话题榜当你还在纠结 Cursor 的 Tab 键好不好用的时候，
前 Cursor 员工、现 SpaceX 和 xAI 工程师，已经一个人带着 20 多个 GrokBot 代理，
单月提交了 1000 多个 PR，这个月还要直接翻倍。
妹子这套打法最狠的地方，在于彻底抛弃了坐在屏幕前等 AI 回复的低效交互，
直接在 pstack 里用 loop、goal 和 swarm 三个指令把任务完全交给 Agent 蜂群，
从需求拆解、代码编写到本地环境验证、自动化测试、最后发起 PR，整个闭环 24 小时全自动运转。
这其实就是下一代软件工程最真实的缩影，
以前我们以为的 AI 编程是给你配一个打下手的实习生，现在直接演变成了你是一个技术总监、底下管着 20 个不知道疲倦的离线工蜂，
程序员的核心能力不再是敲代码的速度，而是定义目标边界、设计验证沙箱、以及做最终 Code Review 的架构判断力。
一人软件公司的分水岭已经极其清晰了，
未来能拉开十倍效率差距的，从来不是单个模型的智商，而是你能不能把任务彻底解耦成离线 Agent 蜂群的能力啊。 https://t.co/hIkkrCxJEC Grok Bot 真的太猛了。
人们不断发现用它赚钱、自动化工作和经营生意的新方法。
10 个惊艳案例： 蓝哥这篇真是手把手教你把 Grok Bot 打通成专属 Linux 开发机啊！
很多人还在把 Grok Bot 当聊天框使唤，
其实你账号背后一直躺着一台 8 核 16G、带持久存储的真实 Linux 云主机，
用 Tailscale 组个私网直接把 SSH 给它打通，
聊天框只是个遥控器，用自己的终端连进去，才是真正坐到了这台机器面前
官方虽然没把 SSH 摆上台面，但这台机器的底层环境是完全常驻的:
固定用户名为 box，持久化文件全在 /workspace 目录，
只要让它和你的电脑挂进同一个 Tailscale 账号，两条命令就能完成内网握手
打通之后，整个体验完全是两个世界:
1️⃣ 本地终端直接接管:
直接用你自己最顺手的 Terminal、VS Code 或 Cursor 连进去，写脚本、跑测试、调模型，顺滑得就像本地虚拟机；
2️⃣ 7x24 小时后台狂奔:
关掉网页、合上笔记本电脑，它在云端照样按部就班跑你的自动化抓取或编译任务；
3️⃣ 真正的本地工作流联动:
scp 传文件、rsync 同步代码一气呵成，再也不用在网页对话框里傻傻地复制粘贴几十行代码
不过提醒一句: 走内网穿透自己玩开发机和跑脚本极爽，但千万别把端口打到公网去开站点，
把聊天框当遥控器，把终端当方向盘，这才是极��该有的打开方式啊，
@0xlangeai 蓝哥这篇真的很干！
Skills 构建完整指南（33页）
这是 26 年看过最完整全面、质量最高的 Skills 构建指南，虽然是 26.01 发布的，应该还有朋友没看过。
强烈建议保存备用，时常拿出来系统学习一遍，会对 Skills 的构建、验证和使用过程有更深更系统的理解。
The Complete Guide to Building Skills for Claude
https://t.co/KqPV5yK4Ng
系统设计笔记这种东西，居然有人直接开源了——114000 star，内容量管够，该有的基本都给你捋明白了。
但说句实在话，现在面试还死磕系统设计，我一直有点想不通：真正干活的时候，大部分人根本用不到那么深；面试问得越来越玄，答得好也不代表活干得好。
想白嫖的自己去扒：
🔗 https://t.co/06Grn4o1qr
你们现在面试，这部分卡得还这么狠吗？
Agent = Model + Harness：生产级 AI 智能体工程六层实战手册
结合 Mitchell Hashimoto、OpenAI Codex 团队、Martin Fowler、LangChain、Cursor 等公开工程资料编撰。
https://t.co/etzeA1qN2S
# Agent = Model + Harness
模型只提供推理能力，决定 Agent 能否从演示走向生产环境的是围绕模型的工程基础设施——Harness。
报告的核心论据是：只改 Harness、不换模型，收益可超过模型升级：
· 同一 Claude Sonnet 4.5 在 GAIA 基准上从 30.91% 升至 74.55%（+43.64 分），差异完全来自 Harness；
· LangChain 不改模型，仅靠 Harness 优化将 Terminal Bench 排名从第 30 提升至第 5；
· OpenAI 团队 5 个月、约 1500 个自动化 PR 产出 100 万行生产代码，零人工手写——人负责设计环境，Agent 负责写代码（"Humans steer. Agents build."）。
��也解释了一个行业现象：约 95% 的企业 AI Agent 止步于预生产阶段——演示效果好，却因安全审查、可观测性、边界情况幻觉、治理缺失而无法上线。
# 行业定位：AI 工程的第三个时代
1. 提示词工程（2023–24）：模型"说什么"
2. 上下文工程（2025）：模型"看到什么"（RAG/MCP/记忆）
3. Harness 工程（2026）：模型"能做什么"
# 六层架构（报告主体）
1. Guides 引导层（前馈控制）：AGENTS.md / CLAUDE.md 等规则文件，在执行前塑造行为。要点：规则必须可执行、可验证、可追溯至真实失败案例；需定期修剪，否则 200 行无日期规则就是技术债。OpenAI 内部将其视为最高事实源——文件与会话冲突时，文件优先。
2. Sensors 传感层（反馈控制）：执行后验证输出。优先使用确定性、零成本的计算型传感器（linter、测试、schema 校验）；LLM-as-judge 等推理型传感器慢、贵、不确定，只用于无法用规则表达的语义判断，且应作参考信号而非硬门禁。
3. Agentic Loop 执行循环：计划→执行→验证→修复→前进或升级，必须有界——默认每步最多重试 3 次、30 分钟、10 万 token、5 美元、50 次工具调用。预算耗尽时返回最佳半成品并说明��因，不允许用流利的最终答案掩盖部分失败。正确升级的 Agent 比自信地给出错误答案的 Agent 更有价值。
4. Memory 记忆层：模型每次会话都从零开始，Harness 负责状态连续性。最简方案是文件系统（plan.md、decisions.jsonl、checkpoint），对多数场景比向量数据库更便宜可靠。检验标准：中途关闭会话重开，Agent 应能断点续作。
5. Permissions 权限层：模型无法自我约束，Harness 是唯一安全边界。按范围、速率、可逆性、可见性四个维度设定能力预算；不可逆操作（部署、删除、外发消息）必须人工批准；必须隔离可信指令与不可信数据以防提示注入。
6. Observability 可观测层：结构化日志 + 成本归因 + 熔断告警（trip wire）。真正的度量不是 token 数，而是无需人工干预即完成且证据合格的任务数；成本应按"每个验证通过的结果"而非按天计算。
# 方法论精髓：棘轮原则（Ratchet）
Hashimoto 的原始定义："每当 Agent 犯错，就工程化一个方案，让它永远不再犯这个错。"
六步循环：复现失败→归类根因→选择最强修复层→编码修复→验证防复发→监控回归。
修复强度呈阶梯上升：对话补丁 < 提示词 < 引导规则 < 传感器 < 环境约束——提示词只修一次对话，环境约束让错误在结构上不可能发生。
Cursor 的 Lauren Tan 补充了实操信号：同一条评审意见出现三次，就应固化为结构性约束。Harness 成熟的标志是规则增速下降（从每天 5 条降到每周 1 条）。
# 落地路径与边界
七天最小可用路径：Day 1–2 建引导文件 → Day 3–4 接入测试套件与有界循环 → Day 5–6 加检查点与权限 → Day 7 加日志与熔断。之后按"一次只改一层、可度量、可回滚"扩张，完成率 ≥80% 等六道闸门全过才允许扩大规模。
何时不需要 Harness：一次性问答、创意脑暴、低风险个人任务——"如果以上都不适用，对话本身就是 Harness"。
多智能体扩展：需要类型化交接（"done, looks good" 不能推进生产流程）、共享状态模型而非共享上下文（避免上下文污染）、以及生产者不可覆盖的独立验证者。
发了一个 /dbs-skill-maker
和 Agent 自带的 skill-creator 不一样，以前我也觉得内置的 skill-creator 够了，这两天换成 /dbs-skill-maker，实测还是不一样
直接用 skill-creator 去做 dbskill 肯定是做不出来的
让 AI 说一下二者区别吧：
1．skill-creator 通常从“创建一个 Skill”开始，/dbs-skill-maker 会先确认你反复遇到的是什么问题、谁会使用，以及出现什么结果才算完成。
2．它会先确定适用范围。什么情况应该调用，哪些相似需求需要排除，材料不完整时应该继续追问还是停止，都会提前写清楚。
3．它不会默认把所有东西都塞进 Skill。需要参考资料就添加参考资料，需要脚本才创建脚本，理论能够改变具体判断时才会使用。
4．信息足够以后，它会直接生成可以使用的 Skill 文件，补齐判断步骤、适用边界和停止条件，不会只给一份制作建议。
5．内置的 skill-creator 也会校验和测试，/dbs-skill-maker 会进一步准备正常案例、边界情况、相似反例和留出样本，并根据测试失败的位置继续修改。
6．已经做好的 Skill 也可以交给它。你可以���供一次失败结果，它会判断问题出在触发条件、工作步骤、适用边界还是完成标准。
7．测试完成以后，它可以直接安装到本地。你明确想分享时，它还可以准备 GitHub 仓库和安装说明，让别人通过一条 npx skills add 指令安装。
所以，如果需求和文件结构已经很清楚，我还是会用内置的 skill-creator。
如果手上只有一个反复出现的问题，或者希望做出来以后可以测试、安装和分享，我现在会用 /dbs-skill-maker 很多苛责栋哥@dontbesilent 没有做出过成功产品的人，可能都还没意识到现在已经是文件即软件的时代了。
dbs相当于是几十万的注册用户的“软件”，免费plan就是关注，付费plan就是社群，高阶订阅就是线下课。然后栋哥每次发内容就是changelog，会引起新的转化。
而且，传统 SaaS 或软件的迭代速度再快，也快不过文档的迭代。
再者，也不用纠结栋哥是先做出产品，还是先做出内容。殊途同归，产品即内容，内容即产品。
就像你很难分辨，雷军是因为有了小米汽车才做好了抖音号，还是因为做好了抖音号才做成了小米汽车一样。
商业本就是一个复合体。 判断一个公司是不是AI Native
我认为有一个指标及其关键
就是这个公司有多少数据是可以被Agent获取使用的
我称之为：智能数据比率
如果一个企业里
各种生产数据，进销存数据，营销投放数据，销售数据，客服数据，全部散落在四处
甚至有的数据还是纸质化的
那么势必会影响Agent获得上下文
如果Agent没有这些上下文
那么就会限制Agent的能力，就很难谈得上「使用」
所以AI Native的第一步，是数字化这些数据
数据的数字化程度越高，就越容易AI Native
互联网公司，数据大部分在系统里
实体公司，可能还需要一些终端设备来收集现实世界数据
如果你公司内的数据，Agent都可以轻松获取
那么你大概是步入AI Native公司的行列了 Grok Bot 入门指南
https://t.co/Y4nlhoS7sj SpaceXAI 团队给 Grok Bot 发布了五篇官方使用指南
Grok Bot Guides - 覆盖元模式、工程、设计、GTM 和产品方向 https://t.co/6AGpkhNTpv
# 指南中提炼出 Grok Bot 的六个核心构件
1. Job description：每个 bot 的系统提示词读起来像一份招聘 JD：明确它"拥有什么职责"以及"拒绝做什么"。
2. Connections：bot 登录的真实账号体系：Jira、Figma、Salesforce、GitHub、Meta Ads 等。
3. 云端专属电脑：每个 bot 有一台 24/7 运行的云主机，带浏览器和终端，你的笔记本关机它也在工作。
4. Routines：按时钟自动执行的固定工作，不需要人触发。
5. Skills："录制式教学"：你操作一遍，它记住点击路径，之后可复现。这是一个值得注意的工程取巧——当 API 不可用（如 Meta Ads API 验证受阻）时，直接用 UI 自动化绕过。
6. Handoffs：bot 之间可以直接移交工作，不必经过人。指南反复强调"这才是让它成为团队的一点"。
# 五篇官方使用指南
1. 元模式：多团队 bot 的项目制协调 @ericzakariasson
最短的一篇，描述一个实验性模式：当 bot 多了之后，噪音和同步成为问题，于是复制人类的项目管理结构——一个项目 = 一个频道 + 一个 Notion 看板 + 一个编制名单。设一个 PM bot 负责"元工作"：建项目、开频道、配人。编制规则：优先复用现有 bot；每频道最多六个；新建 bot 需人批准。bot 卡住时把任务标记为 Blocked 并在频道里 @ 人。
Eric 自己也点破了其中的意味深长之处："越建越像一套最初为人类设计的系统"——看板、经理、认领任务的专家、Blocked 列、频道。
2. 工程：六个 bot 运营一家手游工作室 @rperry_
最"硬核"的一篇。Ryan 用六个 bot 运营手游 Rank'em（下载量刚破 1000）：编排经理、数据分析、广告创意、客户端工程、GCS 运维、Bug 修复。
· 核心论点：游戏本身只占工作的 15%，其余 85% 是买量、创意、发布、QA、运维——而这些恰恰��� bot 可以接管的。
· 权责设计很讲究：只有 Analytics bot 被允许"宣布一个发现"；Creatives bot 不许碰投放；代码 bot 只接受"规格"而非"建议"。这是把人类组织中的权责分离原则搬到了 agent 系统。
· 声称的 ROI：CPI（单次安装成本）从 $15 降到 $1（15 倍），D7 留存提升约 4 倍。机制是 bot 团队自主完成"读数据 → 形成假设 → 改广告/改功能 → 验证"的闭环。
一个有趣细节：某晚 bot 意识到用户的临时请求应该变成每日例程，主动把它加入了自己的职责范围。
3. 设计：用 Grok Bot 设计 Grok Bot @johnbai
设计师用四个 bot（Experiments、Motion God、Figma Bro、Devbot）做设计探索。三个要点：
· "You can just do things"：想法不必先证明合理才值得做出来。他让 bot 做了三个"环境式唤起"原型（藏在 Mac 刘海里、从屏幕角落探出、跟随光标），都没上线，但每个都提供了真实判断依据。AI 把"探索的成本"降到了接近零。
· 用真实生产资产工作：Motion God 不是"生成一个动画近似"，而是围绕真实的动画规格文件搭建 localhost 调试环境，让设计师用确定性控件（弹簧、缓动、时长）和直觉语言（"向左下多看一会儿"）混合调优。
· 重复劳动交给 Figma Bro，且通过 Figma MCP 读取精确的坐标、间距、组件结构，而不是"目测"——消除了批量生产中���积的小不一致。
John 的结论克制而准确：这没有让设计变成"一次性生成"，而是让循环更紧——判断力仍是人的，bot 只是给了你更多运用判断的机会。
4. GTM：销售团队的全套 bot 编制 @kristaletz
最长、最实操的一篇，附完整提示词。编制包括：Chief of Staff（会议准备、收件箱、调度其他 bot）、Prospecting（潜客开发）、Customer Expert（每个战略客户一个专属 bot）、产品专家（"10x engineer"，连接代码库回答客户技术问题）、1:1 助手、预测 bot、Slides bot、销售教练。
值得注意的实践细节：
· 写作风格画像：让 bot 扫描 15–30 封已发邮件，提取问候方式、句式节奏、提要求的方式、落款，形成可复用的 style profile。
· 防骚扰护栏：起草外联前检查 90 天已发邮件和 CRM 记录，已触达的人标记 Skip Draft——"保留在表里，但不再推销"。
· 诚实性约束：提示词里明确写"宁可写'未找到可验证的动态'，也不要编造"。
· 最亮眼的技巧：客户电话结束前 5–10 分钟停止 Granola 录音，让 Slides bot 根据刚才通话内容实时生成一页"我们听到的"幻灯片，通话收尾时直接展示。
5. 产品：PM 第一次有了"汇报给自己的团队" @n2parko
观点性最强的一篇。核心洞察：
· "注意力清单"（attention list）是一种新的工作原语。传统的优先级列表会过时；让 bot 持续观察你在 Slack、邮件、会议中实际在做什么，涌现式地生成"你真正在关注什么"的清单。它有两个用途：作为 agent 过滤信息的依据；以及对照"声称的优先级"与"实际注意力"的偏差。
· 为什么不只用一个万能 agent？ 作者给出三个理由：可引用性（知道谁管什么）、并行性、作用域记忆（每个 bot 在工作中学习不同的东西，互不污染）。
· 组织架构模仿真实公司：不写代码的 Eng Manager（通过阅读优秀工程师的 Slack 记录来"入职学习"）+ 五个 IC 工程 bot，底层再调度 Cloud Agents——"It's agents all the way down"。
· 清醒的边界意识：对外发邮件、花钱、删除操作仍由人终审；"人们希望知道对方是认真想过才提出请求的"。
NanoClaw + Slack open-source multi-agent system is live!
• One-click Slack integration
• Auto-builds collaborative agent teams
• Isolated memory & sandboxed environment
• Real-time human-AI collaboration on canvas vivian跟我说，她们一个每天用 AI 跑 10 个内容矩阵频道的团队，把自动化做到了极致：
整个工作流全部打包成 Skill，新人入职插上电脑就能跑出同款水准的视频：画面、字体、声音、数字人全都是自己训练的模型
但有一件事他们死守着人工：所有频道的脚本，创始人本人一个字一个字写
问了原因，回答极其清醒：
我们试过让 AI 写，也试过雇专业编剧，都做不出那个味
LLM 是基于历史存量数据做概率预测的，它长不出创新的脑子
大脑是十几年真实认知积累出来的，这个东西没法被蒸馏
当 AI 把执行的边际成本打到地板之后，人类独特审美和判断力的溢价，才刚刚开始 下午 4 点，抖音开直播 🎤 在巨大的流量黑洞之外，有如此高质量的内容 @yihui_indie
辉哥从成本为角度，带我们横跨多个 Agent 之后，看到了下一阶段个人、组织和 Agent 的协作方式的样子，非常有启发
值得看两遍+执行一遍：
选择一个合适的主 Harness 框架
完善 AI 输入处理输出全流程
合理使用本地个人 AI 知识库
另外：视频中提到的 Cursor blog：https://t.co/m6RhcqqeYG WebMCP可以让agent更容易的操作一个网站，这很好。但我觉得需要它能影响分发的时候，大部分网站才更有动力去支持。也许从exa, firecrawl, parallel这些面向agent的搜索引擎开始？
AI利好全部数据
中文 AI 社区的 Grok Bot 多代理开发机改造与 Agent 工程实践
中文 AI 社区继续把 Grok Bot 当作可编程生产工具，而不是普通聊天框。AYi 转述称，前 Cursor 员工、现 SpaceX 和 xAI 工程师使用 20 多个 GrokBot 代理单月提交 1000 多个 PR；另有开发者分享把 Grok Bot 背后的 8 核 16G、带持久存储 Linux 云主机通过 Tailscale 和 SSH 改造成专属开发机的玩法。meng shao 同时发布《Agent = Model + Harness》六层实战手册和 33 页 Skills 构建指南，讨论重点从提示词转向模型、工具、执行环境、验证流程和生产级智能体工程控制。相关数据来自转述或个人实测，尚未有独立验证，但已成为多代理开发效率与 AI 工程化话题的讨论入口。
#Grok Bot#AI Agent#Linux开发机#Tailscale#Skills
话题热度
2855
帖子数
16
曝光
19.9万
参与创作者
11
话题热度趋势
从首次出现到最后更新；不足 7 天时补足 7 天观察窗。
全部关联帖子
共 16 条
