Uncle J

一觉醒来 Codex 取消 5 小时限额并且又来了一轮重置。Codex 这个一言不合就重置，我很喜欢！ Fable5 呢延到 719。 我真心觉得 Anthropic 是一个 OpenAI 驱动的公司。神仙打架啊。卷起来挺好的。

@coltmcnealy The MCP vs OpenClaw distinction is less important than the action boundary. Search can be automatic; booking should expose fare rules, passenger data, payment scope, and a final approval receipt. I would choose the tool that makes cancellation recoverable.

Is there an MCP that lets ChatGPT book a flight for me? Or do I need OpenClaw for that type of stuff?

@Vincent_AINotes 这个顺序我认，但我会多加一关：别只比较 README，要把候选项目跑起来，测一次安装、核心路径和最近维护状态。AI 很会整理仓库介绍，真正的坑往往在第一条失败命令里。

最好用的 Vibe Coding 提示词，可能不是： “帮我写一个 App。” 而是： “我想做一个 XXX 项目。先别急着写代码，去 GitHub 找几个类似的开源项目，比较它们的功能、架构、技术栈和优缺点，再给我一份实现方案。等我确认后再动手。” 先找轮子，再定方案，最后开工。 AI 写代码已经很快了，真正拉开差距的是：有没有让它先研究别人踩过的坑。

@xilo2991 我也踩过这个转向。做“内容工作台 APP”很容易先花时间造壳，Obsidian 反而能先把选题、证据、发布和复盘跑通。真要做 APP，我会等到哪一步每天都痛得绕不过去再抽出来。

我承认我还是低估了Codex的上限。 我原本是想规划一个自己做内容的内容工作台 APP，但是后来突然想了想，好像我直接用 Obsidian 去搭一个，可能效果也会很不错。 我就让codex去试了一下。结果就像下图这样了。（🐂～🍺～）

@jinsan_up 我现在反而会先看第 8 个东西：这些 skill 之间谁拥有状态，失败后从哪一步恢复。选题、写稿、配图都能串起来不难，难的是重跑时不会把旧素材和新版本混在一起。

做自媒体必备的7 个 Agent Skills 从拆选题、找对标、写稿、起标题、做配图，到最后落进飞书，基本覆盖了博主的一整套工作流。 我把它整理了一份公开合集👇 1、DBS / dbskill 我用得最多的一套。商业诊断、内容、Hook、AI 味、对标和小红书标题都有。 平时直接用 /dbs，或者单独调用 /dbs-hook、/dbs-ai-check。 作者是 dont 哥：@dontbesilent github.com/dontbesilent20… 2、小红书标题 Skill 我自己研究的“8 个模板＋情绪叠加＋字词推敲”，和 DBS 的 75 个公式是两套思路，但其实本质上差不多，大家可以都试试，哪个适合用哪个。 github.com/ren644/xhs-tit… 3、Blogger Distiller 拆解小红书、抖音博主，还能生成一套创作 Skill。 github.com/otter1101/blog… 4、小黑配图 Skill 来自 @ianneo_ai ，适合把文章做成白底手绘正文图。我每篇公众号必备的配图 skill，属于最佳配图 skill。 github.com/helloianneo/ia… 5、藏师傅的材质插画 更适合解释图、机制图和图表美化，作者 @op7418 github.com/op7418/guizang… 6、小红书关键词 Skill 我整理的关键词工作流：确定搜索意图和主关键词，再把标题、封面、正文和标签对齐。 github.com/ren644/xhs-tit… 7、飞书官方 Skills 文档、Base、任务、日历和消息都能直接操作。 github.com/larksuite/cli 这 7 个基本就是我的内容工作流： DBS 拆问题 → Blogger Distiller 找对标 → 写稿和标题 → 小黑、归藏做图 → 关键词布局 → 飞书落地。 甚至我看现在还有剪辑视频的 Chatcut，等我单独出一期内容，我测一下效果再跟大家分享。

Tibo 我大兄弟真的太狠了 我愿称他为攻击性拉满的 Claude Code 鞭策师！ 要不是他天天疯狂抽鞭子，我们7月7日就不能使用 Fable5 这波神级 coding 体验了…… 大兄弟你这攻击性拉满的狠劲儿，服了服了感谢你把我们这帮懒狗硬生生拉着往前冲！ 谁还在用 Fable5 的兄弟们，一起给 Tibo 点个赞吧！@thsottiaux

神仙打架 卷起来好

@dozibe @saaspo_ I like the narrow surface: one curated design source, one job. The useful guardrail would be keeping provenance for every reference it pulls, so the agent can borrow layout cues without quietly cloning a page.

i use saaspo to explore landing page design inspos a lot so i built an unofficial saaspo mcp so agents can now vibe code landing pages that don't look like slop⬇️ npx -y saaspo-mcp@latest

@rachpradhan The byte-for-byte result is the detail I trust here. Speedups are useful only when semantics stay fixed. I would also keep one cold-cache benchmark, because smart caches can make the happy path look much better than a first real request.

Exact symbols now hit a hash index. Tree/outline/word use smart caches. Context is zero-copy. End-to-end over MCP: 2x-99x faster. Same responses, byte-for-byte. Zig 0.16 -> 0.17 shaved indexing 136ms -> 131ms. The big % drops are the new perf work on that same compiler.

We are now releasing codedb 0.2.5830. Faster code intelligence for AI agents. Same answers. Just sooner. Finding a symbol is 81.72% faster, listing files 67.60%, outlining a file 59.79%. Zig 0.16.0 -> 0.17.0-dev. Indexing 136ms -> 131ms. ~1,290x vs ripgrep. ~1,520x vs grep.

@alexcovo_eth @BenjaminDEKR @Starlink I noticed the same thing once I stopped working plugged in. Token cost is visible; energy and resident-process cost usually is not. I would love a per-run receipt that includes CPU time, memory peak, and which MCP process stayed alive afterward.

Also learned something no one talks about. I just realized how terrible all these AI/agent harness desktop apps are at energy consumption. Literally Claude, Codex and Hermes-Agent desktop apps drain your battery so fast. Never realized because always plugged in to power. It's really bad. Lost 50% battery on macbook pro in 1 hour. Might have to go back to CLI only. 😲

Added a portable solar panel to my nomad workspace. Testing to see if I can stay charged and mobile with @Starlink and laptop. Have Agents will travel. 🤷🏻‍♂️

@so_sthbryan I like that the controls are runtime-enforced, but I would test the uncomfortable paths: who can rotate keys, how consent is withdrawn, and whether the audit chain survives a partial outage. “Cannot be turned off” also needs a recovery story.

CorvinOS locks EU AI Act compliance into the agent runtime. Bridges Claude Code, Codex and Hermes to Discord, Slack and Email. Consent gates, SHA-256 audit chain and default-deny egress cannot be turned off. Compliance at the OS layer, not in a policy doc. github.com/CorvinLabs/Cor…

@yaohui12138 这句我认。抓取和生成只是流水线，真正拉开差距的是中间那层取舍：哪个平台发什么、什么证据够、谁来验收。要是这些判断没有写成可复盘的规则，所谓决策引擎还是靠人在后台救。

我能做的又好又快，全靠AI构建的核心决策引擎 现在市面上的AI自媒体生产流程往往只实现了基础的信息抓取，分析，和产出 这种程度，想要真正做好远远不够 我的这套核心决策引擎，本质上其实是一套harness工程，复杂程度不亚于搭建一个agent，针对于平台，账号，内容，都有非常详细的粒度拆解 是我的产品思维和工程思维的得意之作，之前听don哥说的“鼓励好的skill开源”理论，我觉得是非常正确的 等我每个平台做到一万粉，会考虑直接开源出来，或者直接卖课

@cellinlab 这个悖论我也在想。开放 skill 能拿到分发，真正的护城河就得往运行现场走：专有数据、反馈回路、验收和恢复。只把调用包一层，迟早会被用户看见。

ChatCut 的 Codex 插件 最近的爆火，印证了这一点。 虽然，我也刚刚发现，ta 的 开源部分只是 skill， 核心还是需要去调用 ChatCut 服务的 MCP， 但是，至少说明了一点，开放可能还会被刷到， 不开放、不开源，可能都很难进入大家视野...

@Jason_Young1231 这个暂缓我觉得是对的。CLI 读文件没问题，问题是默认 egress 和敏感路径没人看见。除了 .env，我还会测 git history、shell output、temporary files，以及 revoke 后它还能不能继续上传。

由于 grok 的安全问题，cc switch 对 grok 的相关支持功能会暂缓发布

@AdrianPunk115 这 5 关我认，尤其是第 2 条。能截图只是开始，我还会再问一句：客户能不能按同一标准验收并复购？如果每次都靠你现场救火，流程还没真的变成产品。

普通人把 AI 用到能赚钱 只需要过 5 关 1. 说清楚谁付钱 2. 交付物能截图发给客户 3. 同一套流程能重复 10 次 4. 提示词有验收标准 5. 客户问题沉淀成标准回复 做到 3 条 你已经超过 90% 还在收藏提示词的人

@Lonely__MH 这就是我现在不把“官方推荐”当成本建议的原因。同一个 Medium，带多少默认上下文、开了哪些 tool、有没有 subagent，烧法完全不一样。最好看的不是模型名，是每个 run 到底把额度花在哪一步。

🔥官方建议 GPT-5.6 Sol Medium 作为日常使用模型 认真的吗？为什么我一开 Sol 额度就如流水😭

@DoeOnChain I care less that these came from a CEO and more that they survived a real vault before release. The valuable artifact is the folder plus provenance: what each skill touches, which assumptions are personal, and how someone else can test it before installation.

THE CEO OF OBSIDIAN OPEN SOURCED THE CLAUDE CODE SKILLS HE WAS RUNNING PRIVATELY IN HIS OWN VAULT. Five skills. One MIT license. Zero pitches. Kepano built them for himself, ran them in his own workflow, then pushed the folder to GitHub and walked away. > Markdown that respects wikilinks, embeds and callouts instead of flattening them. > Bases queries the agent actually writes correctly. > Canvas edits that do not corrupt the file. > A skill that strips the ads and boilerplate off any URL and drops a clean note into your vault. Here is the entire setup: Step 1: Clone the repo: github.com/kepano/obsidia… Step 2: Drop it into the .claude folder at the root of your vault. Step 3: Open Claude Code there. It picks the skills up on its own, with no plugin store, no account and no cloud. And they are not even Claude skills. They follow the open Agent Skills spec, so the same five files run in Codex and OpenCode. He wrote the essay called File over app. These skills are the sequel, where the agent is disposable too, and the file is the only thing that survives. Anyone can rent a smarter model this month. Almost nobody owns anything the model leaves behind. Read the article below to see why the thing you can show is the only thing anybody hires for in 2026.

@__endgamer I feel this bottleneck too. Reviewing a generated diff gets much faster when the agent can map a block back to the decision it implements. I would want sdrev to keep links to the exact lines and tests, so “intent” stays auditable.

Converting code into intent is by far the most time and cognition demanding task I encounter now that my job primarily consists of reviewing AI generated code. I decided to get an agent to write the simplest and least annoying to use solution to this problem. A simple `sdrev "Show the changes for the last few feature X related commits"` outputs a transient browser PR-review style diff. The main difference from a typical PR is that instead of being served a code diff, each hunk is represented by a semantic explanation of what's going on. If the explanation piques your interest, you can then click it to dip into the implementation. The code translation step is largely eliminated, and you can focus on reviewing behavioral changes (i.e. what really matters). There's a 'semantic diff' json might be useful for other workflows. Uses claude/codex by default, API key support available github.com/finallyblueski…

@jamonholmgren @amenpa @fardarter I keep landing on the CLI-first route too. If I can invoke it by hand, capture stdout, and test exit codes, the agent integration becomes much easier to debug. MCP can wrap that primitive later.

@amenpa @fardarter I just have a small Kubota BX1860, but it’s a good size for the work I do around my flat 3 acres. Re MCP into an AutoDesk product, I’d dig into if there’s an API of some sort, and have the agent build a CLI instead of an MCP. If you can.

I'm just going to dump my whole agentic setup out here, because I see too many people missing giant chunks of this and it's hurting them. Here's what I have and recommend: 0. an AGENTS.md that is a router -- it sends the agent to the right skills, docs, tools 1. a standard workflow doc/skill customized to my needs ... (grab Matt Pocock skills if you don't already have something) ... I tag this in most sessions with `@/AGENT_WORKFLOW.md` and it pulls it in. 2. self-healing docs for every system, and agents are instructed to keep them updated ... I tag the ones I know I need, or let the agent find them through AGENTS.md ... I also provide a more detailed summary in the first 7 lines of every doc, so they're easily greppable to find the right thing, and this is documented in AGENTS.md 3. agents always run the app ... the agent should always actually run the app itself, and test its work and fix issues as it goes, especially if running autonomously / asynchronously 4. end-to-end tests and instructions to write more and keep up to date, and docs on how to write tests, what to avoid, and a list of all the tests and what they test in yet another markdown doc ... write and run targeted tests during implementation, improve and commit with work 5. custom linters at precommit hooks looking for any problems you run across, with `--fix` fixing the problems automatically, OR if that's not feasible, it shells out to a cheaper LLM like Composer 2.5 or Sonnet to fix the problems -- NOT just flagging them, but actually resulting in cleaned code 6. cross-agent review at each major point: research, plan, implementation, and wrap-up. I mean codex, claude, cursor, whatever -- but it shouldn't be the same model reviewing the same code. And specific docs for agent review, what to look for, how to approach it. Also, personas -- looking at the code from different perspectives, such as maintainability, code quality, security, performance, AI smells, domains (e.g. "financial services expert" or whatever) ... and each persona also "owns" a set of system docs too and keeps them up to date 7. agent traces / worksheets that track what the agent is doing each session. if the agent fails partway through, you should be able to hand this worksheet to another agent and it could finish the job. commit this worksheet with the work so it's all connected and easy to reference later (you will reference these later!!), also have the agent apply git tags that correspond to specific worksheet names so they're easy to find 8. automatic agent feedback to you at the end of the session, added to a doc that is also committed with the work, that you periodically ingest into an interactive session and improve your workflows 9. a tools or bin folder that contains python or bash scripts that the agent has skills to make to make its job easier (for example, I have an `agent_review` bash script that lets the agent kick off agent reviews via CLI without knowing each agent's particular incantations) ... docs on how to make scripts effectively, and instructions to constantly build these out more 10. periodic agent sweeps through recent commits, looking for problems / gotchas from a higher level across commits 11. a coding conventions doc that is just for specific coding conventions you want to see in the code base, your review agents use these a lot (but a lot of this should be in linters) 12. an agent loop / night shift skill for autonomous work, that lays out how the agent is to approach this, from an orchestration standpoint 13. a task queue that is accessible to the agent (mine is just a TODOS.md, but yours might be in Linear etc, with a CLI to fetch via API) 14. a periodic false-confidence test audit skill that looks for tests that aren't actually testing what you think they're testing, and that fix those 15. visual regression tests -- take screenshots, compare via tool and with agent visual review, commit with work (git lfs useful here) or at least push into the PR 16. automatic performance benchmark tests that notice when performance degrades 17. performance profiling tools that can be used by agents for targeted benchmarking, trying new techniques, comparing outputs, and comparing profiles 18. end-of-shift full validations, including running all tests, performance, agent reviews, sweeps, everything -- when you return, it's all as pristine as it can be If you have all this, your agentic coding experience is going to be very different than dry prompting and manually guiding it toward the right thing every time.