diff --git a/.githooks/pre-commit b/.githooks/pre-commit new file mode 100755 index 0000000..1991206 --- /dev/null +++ b/.githooks/pre-commit @@ -0,0 +1,7 @@ +#!/bin/sh +set -eu + +ROOT="$(git rev-parse --show-toplevel)" +cd "$ROOT" + +python3 scripts/check_article_quality.py --staged diff --git a/.github/workflows/article-quality.yml b/.github/workflows/article-quality.yml new file mode 100644 index 0000000..e53edfa --- /dev/null +++ b/.github/workflows/article-quality.yml @@ -0,0 +1,23 @@ +name: Article Quality + +on: + pull_request: + paths: + - "**/*.md" + - "scripts/check_article_quality.py" + - ".github/workflows/article-quality.yml" + +permissions: + contents: read + +jobs: + article-quality: + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@v4 + with: + fetch-depth: 0 + + - name: Check changed articles + run: python3 scripts/check_article_quality.py --base "${{ github.event.pull_request.base.sha }}" --head HEAD diff --git a/.github/workflows/pages.yml b/.github/workflows/pages.yml new file mode 100644 index 0000000..ca3f309 --- /dev/null +++ b/.github/workflows/pages.yml @@ -0,0 +1,76 @@ +name: Redirect GitHub Pages to Vercel + +on: + push: + branches: + - master + workflow_dispatch: + +permissions: + contents: read + pages: write + id-token: write + +concurrency: + group: pages + cancel-in-progress: true + +jobs: + deploy: + environment: + name: github-pages + url: https://cxuan-labs.vercel.app/ + runs-on: ubuntu-latest + steps: + - name: Configure Pages + uses: actions/configure-pages@v5 + + - name: Prepare redirect site + run: | + mkdir _site + cat > _site/index.html <<'HTML' + + + + + + + + + Moved to Vercel + + + +

This site has moved to cxuan-labs.vercel.app.

+ + + HTML + cp _site/index.html _site/404.html + touch _site/.nojekyll + + - name: Upload artifact + uses: actions/upload-pages-artifact@v3 + with: + path: _site + + - name: Deploy redirect to GitHub Pages + id: deployment + uses: actions/deploy-pages@v4 diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..adaa37c --- /dev/null +++ b/.gitignore @@ -0,0 +1,8 @@ +.DS_Store +.claude/ +.playwright-cli +.vercel +_site +output/ +dist/ +node_modules/ diff --git a/.nojekyll b/.nojekyll new file mode 100644 index 0000000..8b13789 --- /dev/null +++ b/.nojekyll @@ -0,0 +1 @@ + diff --git a/.vercelignore b/.vercelignore new file mode 100644 index 0000000..0500335 --- /dev/null +++ b/.vercelignore @@ -0,0 +1,6 @@ +.DS_Store +.git +.github +.githooks +.vercel +_site diff --git a/404.html b/404.html new file mode 100644 index 0000000..1b6438f --- /dev/null +++ b/404.html @@ -0,0 +1,38 @@ + + + + + + + Redirecting... + + + + + diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..0c64c09 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,25 @@ +# 投稿内容质量规则 + +这个仓库不接收只有一句话、几句话或缺少完整文章逻辑的 Markdown 文章。 + +新增或修改 `ai-articles/`、`archive-bestjavaer/` 下的文章时，需要至少满足： + +- 正文有效内容不少于 600 个字符； +- 至少 5 个有效段落； +- 至少 8 个有效句子； +- 图片、链接、日期、代码块不能替代正文论述。 +- 图片不能裂：本地图片必须放在仓库内并随文章一起提交，不能引用 `/Users/...`、Typora 临时目录等本机绝对路径；远程图片链接需要能正常访问。 + +本地提交前会运行： + +```sh +python3 scripts/check_article_quality.py --staged +``` + +首次克隆仓库后，需要启用内置 hook： + +```sh +git config core.hooksPath .githooks +``` + +PR 和 GitHub Pages 部署也会运行同一套检查。若检查失败，请先把文章补成完整内容，再重新提交。 diff --git a/LICENSE b/LICENSE new file mode 100644 index 0000000..2d58298 --- /dev/null +++ b/LICENSE @@ -0,0 +1,428 @@ +Attribution-ShareAlike 4.0 International + +======================================================================= + +Creative Commons Corporation ("Creative Commons") is not a law firm and +does not provide legal services or legal advice. Distribution of +Creative Commons public licenses does not create a lawyer-client or +other relationship. Creative Commons makes its licenses and related +information available on an "as-is" basis. Creative Commons gives no +warranties regarding its licenses, any material licensed under their +terms and conditions, or any related information. Creative Commons +disclaims all liability for damages resulting from their use to the +fullest extent possible. + +Using Creative Commons Public Licenses + +Creative Commons public licenses provide a standard set of terms and +conditions that creators and other rights holders may use to share +original works of authorship and other material subject to copyright +and certain other rights specified in the public license below. The +following considerations are for informational purposes only, are not +exhaustive, and do not form part of our licenses. + + Considerations for licensors: Our public licenses are + intended for use by those authorized to give the public + permission to use material in ways otherwise restricted by + copyright and certain other rights. Our licenses are + irrevocable. Licensors should read and understand the terms + and conditions of the license they choose before applying it. + Licensors should also secure all rights necessary before + applying our licenses so that the public can reuse the + material as expected. Licensors should clearly mark any + material not subject to the license. This includes other CC- + licensed material, or material used under an exception or + limitation to copyright. More considerations for licensors: + wiki.creativecommons.org/Considerations_for_licensors + + Considerations for the public: By using one of our public + licenses, a licensor grants the public permission to use the + licensed material under specified terms and conditions. If + the licensor's permission is not necessary for any reason--for + example, because of any applicable exception or limitation to + copyright--then that use is not regulated by the license. Our + licenses grant only permissions under copyright and certain + other rights that a licensor has authority to grant. Use of + the licensed material may still be restricted for other + reasons, including because others have copyright or other + rights in the material. A licensor may make special requests, + such as asking that all changes be marked or described. + Although not required by our licenses, you are encouraged to + respect those requests where reasonable. More considerations + for the public: + wiki.creativecommons.org/Considerations_for_licensees + +======================================================================= + +Creative Commons Attribution-ShareAlike 4.0 International Public +License + +By exercising the Licensed Rights (defined below), You accept and agree +to be bound by the terms and conditions of this Creative Commons +Attribution-ShareAlike 4.0 International Public License ("Public +License"). To the extent this Public License may be interpreted as a +contract, You are granted the Licensed Rights in consideration of Your +acceptance of these terms and conditions, and the Licensor grants You +such rights in consideration of benefits the Licensor receives from +making the Licensed Material available under these terms and +conditions. + + +Section 1 -- Definitions. + + a. Adapted Material means material subject to Copyright and Similar + Rights that is derived from or based upon the Licensed Material + and in which the Licensed Material is translated, altered, + arranged, transformed, or otherwise modified in a manner requiring + permission under the Copyright and Similar Rights held by the + Licensor. For purposes of this Public License, where the Licensed + Material is a musical work, performance, or sound recording, + Adapted Material is always produced where the Licensed Material is + synched in timed relation with a moving image. + + b. Adapter's License means the license You apply to Your Copyright + and Similar Rights in Your contributions to Adapted Material in + accordance with the terms and conditions of this Public License. + + c. BY-SA Compatible License means a license listed at + creativecommons.org/compatiblelicenses, approved by Creative + Commons as essentially the equivalent of this Public License. + + d. Copyright and Similar Rights means copyright and/or similar rights + closely related to copyright including, without limitation, + performance, broadcast, sound recording, and Sui Generis Database + Rights, without regard to how the rights are labeled or + categorized. For purposes of this Public License, the rights + specified in Section 2(b)(1)-(2) are not Copyright and Similar + Rights. + + e. Effective Technological Measures means those measures that, in the + absence of proper authority, may not be circumvented under laws + fulfilling obligations under Article 11 of the WIPO Copyright + Treaty adopted on December 20, 1996, and/or similar international + agreements. + + f. Exceptions and Limitations means fair use, fair dealing, and/or + any other exception or limitation to Copyright and Similar Rights + that applies to Your use of the Licensed Material. + + g. License Elements means the license attributes listed in the name + of a Creative Commons Public License. The License Elements of this + Public License are Attribution and ShareAlike. + + h. Licensed Material means the artistic or literary work, database, + or other material to which the Licensor applied this Public + License. + + i. Licensed Rights means the rights granted to You subject to the + terms and conditions of this Public License, which are limited to + all Copyright and Similar Rights that apply to Your use of the + Licensed Material and that the Licensor has authority to license. + + j. Licensor means the individual(s) or entity(ies) granting rights + under this Public License. + + k. Share means to provide material to the public by any means or + process that requires permission under the Licensed Rights, such + as reproduction, public display, public performance, distribution, + dissemination, communication, or importation, and to make material + available to the public including in ways that members of the + public may access the material from a place and at a time + individually chosen by them. + + l. Sui Generis Database Rights means rights other than copyright + resulting from Directive 96/9/EC of the European Parliament and of + the Council of 11 March 1996 on the legal protection of databases, + as amended and/or succeeded, as well as other essentially + equivalent rights anywhere in the world. + + m. You means the individual or entity exercising the Licensed Rights + under this Public License. Your has a corresponding meaning. + + +Section 2 -- Scope. + + a. License grant. + + 1. Subject to the terms and conditions of this Public License, + the Licensor hereby grants You a worldwide, royalty-free, + non-sublicensable, non-exclusive, irrevocable license to + exercise the Licensed Rights in the Licensed Material to: + + a. reproduce and Share the Licensed Material, in whole or + in part; and + + b. produce, reproduce, and Share Adapted Material. + + 2. Exceptions and Limitations. For the avoidance of doubt, where + Exceptions and Limitations apply to Your use, this Public + License does not apply, and You do not need to comply with + its terms and conditions. + + 3. Term. The term of this Public License is specified in Section + 6(a). + + 4. Media and formats; technical modifications allowed. The + Licensor authorizes You to exercise the Licensed Rights in + all media and formats whether now known or hereafter created, + and to make technical modifications necessary to do so. The + Licensor waives and/or agrees not to assert any right or + authority to forbid You from making technical modifications + necessary to exercise the Licensed Rights, including + technical modifications necessary to circumvent Effective + Technological Measures. For purposes of this Public License, + simply making modifications authorized by this Section 2(a) + (4) never produces Adapted Material. + + 5. Downstream recipients. + + a. Offer from the Licensor -- Licensed Material. Every + recipient of the Licensed Material automatically + receives an offer from the Licensor to exercise the + Licensed Rights under the terms and conditions of this + Public License. + + b. Additional offer from the Licensor -- Adapted Material. + Every recipient of Adapted Material from You + automatically receives an offer from the Licensor to + exercise the Licensed Rights in the Adapted Material + under the conditions of the Adapter's License You apply. + + c. No downstream restrictions. You may not offer or impose + any additional or different terms or conditions on, or + apply any Effective Technological Measures to, the + Licensed Material if doing so restricts exercise of the + Licensed Rights by any recipient of the Licensed + Material. + + 6. No endorsement. Nothing in this Public License constitutes or + may be construed as permission to assert or imply that You + are, or that Your use of the Licensed Material is, connected + with, or sponsored, endorsed, or granted official status by, + the Licensor or others designated to receive attribution as + provided in Section 3(a)(1)(A)(i). + + b. Other rights. + + 1. Moral rights, such as the right of integrity, are not + licensed under this Public License, nor are publicity, + privacy, and/or other similar personality rights; however, to + the extent possible, the Licensor waives and/or agrees not to + assert any such rights held by the Licensor to the limited + extent necessary to allow You to exercise the Licensed + Rights, but not otherwise. + + 2. Patent and trademark rights are not licensed under this + Public License. + + 3. To the extent possible, the Licensor waives any right to + collect royalties from You for the exercise of the Licensed + Rights, whether directly or through a collecting society + under any voluntary or waivable statutory or compulsory + licensing scheme. In all other cases the Licensor expressly + reserves any right to collect such royalties. + + +Section 3 -- License Conditions. + +Your exercise of the Licensed Rights is expressly made subject to the +following conditions. + + a. Attribution. + + 1. If You Share the Licensed Material (including in modified + form), You must: + + a. retain the following if it is supplied by the Licensor + with the Licensed Material: + + i. identification of the creator(s) of the Licensed + Material and any others designated to receive + attribution, in any reasonable manner requested by + the Licensor (including by pseudonym if + designated); + + ii. a copyright notice; + + iii. a notice that refers to this Public License; + + iv. a notice that refers to the disclaimer of + warranties; + + v. a URI or hyperlink to the Licensed Material to the + extent reasonably practicable; + + b. indicate if You modified the Licensed Material and + retain an indication of any previous modifications; and + + c. indicate the Licensed Material is licensed under this + Public License, and include the text of, or the URI or + hyperlink to, this Public License. + + 2. You may satisfy the conditions in Section 3(a)(1) in any + reasonable manner based on the medium, means, and context in + which You Share the Licensed Material. For example, it may be + reasonable to satisfy the conditions by providing a URI or + hyperlink to a resource that includes the required + information. + + 3. If requested by the Licensor, You must remove any of the + information required by Section 3(a)(1)(A) to the extent + reasonably practicable. + + b. ShareAlike. + + In addition to the conditions in Section 3(a), if You Share + Adapted Material You produce, the following conditions also apply. + + 1. The Adapter's License You apply must be a Creative Commons + license with the same License Elements, this version or + later, or a BY-SA Compatible License. + + 2. You must include the text of, or the URI or hyperlink to, the + Adapter's License You apply. You may satisfy this condition + in any reasonable manner based on the medium, means, and + context in which You Share Adapted Material. + + 3. You may not offer or impose any additional or different terms + or conditions on, or apply any Effective Technological + Measures to, Adapted Material that restrict exercise of the + rights granted under the Adapter's License You apply. + + +Section 4 -- Sui Generis Database Rights. + +Where the Licensed Rights include Sui Generis Database Rights that +apply to Your use of the Licensed Material: + + a. for the avoidance of doubt, Section 2(a)(1) grants You the right + to extract, reuse, reproduce, and Share all or a substantial + portion of the contents of the database; + + b. if You include all or a substantial portion of the database + contents in a database in which You have Sui Generis Database + Rights, then the database in which You have Sui Generis Database + Rights (but not its individual contents) is Adapted Material, + including for purposes of Section 3(b); and + + c. You must comply with the conditions in Section 3(a) if You Share + all or a substantial portion of the contents of the database. + +For the avoidance of doubt, this Section 4 supplements and does not +replace Your obligations under this Public License where the Licensed +Rights include other Copyright and Similar Rights. + + +Section 5 -- Disclaimer of Warranties and Limitation of Liability. + + a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE + EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS + AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF + ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, + IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, + WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR + PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, + ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT + KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT + ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. + + b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE + TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, + NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, + INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, + COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR + USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN + ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR + DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR + IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. + + c. The disclaimer of warranties and limitation of liability provided + above shall be interpreted in a manner that, to the extent + possible, most closely approximates an absolute disclaimer and + waiver of all liability. + + +Section 6 -- Term and Termination. + + a. This Public License applies for the term of the Copyright and + Similar Rights licensed here. However, if You fail to comply with + this Public License, then Your rights under this Public License + terminate automatically. + + b. Where Your right to use the Licensed Material has terminated under + Section 6(a), it reinstates: + + 1. automatically as of the date the violation is cured, provided + it is cured within 30 days of Your discovery of the + violation; or + + 2. upon express reinstatement by the Licensor. + + For the avoidance of doubt, this Section 6(b) does not affect any + right the Licensor may have to seek remedies for Your violations + of this Public License. + + c. For the avoidance of doubt, the Licensor may also offer the + Licensed Material under separate terms or conditions or stop + distributing the Licensed Material at any time; however, doing so + will not terminate this Public License. + + d. Sections 1, 5, 6, 7, and 8 survive termination of this Public + License. + + +Section 7 -- Other Terms and Conditions. + + a. The Licensor shall not be bound by any additional or different + terms or conditions communicated by You unless expressly agreed. + + b. Any arrangements, understandings, or agreements regarding the + Licensed Material not stated herein are separate from and + independent of the terms and conditions of this Public License. + + +Section 8 -- Interpretation. + + a. For the avoidance of doubt, this Public License does not, and + shall not be interpreted to, reduce, limit, restrict, or impose + conditions on any use of the Licensed Material that could lawfully + be made without permission under this Public License. + + b. To the extent possible, if any provision of this Public License is + deemed unenforceable, it shall be automatically reformed to the + minimum extent necessary to make it enforceable. If the provision + cannot be reformed, it shall be severed from this Public License + without affecting the enforceability of the remaining terms and + conditions. + + c. No term or condition of this Public License will be waived and no + failure to comply consented to unless expressly agreed to by the + Licensor. + + d. Nothing in this Public License constitutes or may be interpreted + as a limitation upon, or waiver of, any privileges and immunities + that apply to the Licensor or You, including from the legal + processes of any jurisdiction or authority. + + +======================================================================= + +Creative Commons is not a party to its public +licenses. Notwithstanding, Creative Commons may elect to apply one of +its public licenses to material it publishes and in those instances +will be considered the “Licensor.” The text of the Creative Commons +public licenses is dedicated to the public domain under the CC0 Public +Domain Dedication. Except for the limited purpose of indicating that +material is shared under a Creative Commons public license or as +otherwise permitted by the Creative Commons policies published at +creativecommons.org/policies, Creative Commons does not authorize the +use of the trademark "Creative Commons" or any other trademark or logo +of Creative Commons without its prior written consent including, +without limitation, in connection with any unauthorized modifications +to any of its public licenses or any other arrangements, +understandings, or agreements concerning use of licensed material. For +the avoidance of doubt, this paragraph does not form part of the +public licenses. + +Creative Commons may be contacted at creativecommons.org. + diff --git a/LICENSE-MIT b/LICENSE-MIT new file mode 100644 index 0000000..98e3312 --- /dev/null +++ b/LICENSE-MIT @@ -0,0 +1,21 @@ +MIT License + +Copyright (c) 2026 crisxuan + +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the "Software"), to deal +in the Software without restriction, including without limitation the rights +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in all +copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE +SOFTWARE. diff --git a/OPEN_SOURCE_IMPACT.md b/OPEN_SOURCE_IMPACT.md new file mode 100644 index 0000000..dd2bcbd --- /dev/null +++ b/OPEN_SOURCE_IMPACT.md @@ -0,0 +1,59 @@ +# Open Source Impact + +## Project Summary + +bestJavaer / cxuan-ai-labs is an open-source AI coding workflow and developer education lab for Chinese-speaking developers. + +The project documents practical AI-assisted development workflows, Agent experiments, curated tools, reproducible notes, and real failure cases. It is written mainly in Chinese so that Chinese-speaking developers can learn from concrete examples instead of only reading abstract product announcements. + +The repository started as a long-running Java learning project. That historical material is preserved in the archive, but the current project narrative is not "a Java repo." The current main line is an AI coding workflow lab and open developer education resource. + +## Audience + +The project serves Chinese-speaking developers around the world, including independent developers, students, open-source maintainers, and working engineers who are learning how to use AI tools responsibly in real software and documentation workflows. + +It should not be described as a mainland-China commercial project. The value is open developer education for a Chinese-speaking technical audience. + +## Open Source Value + +- Provides Chinese-language documentation for AI coding workflows, Agent usage patterns, tool evaluation, and practical failure cases. +- Curates useful AI resources and open-source projects that developers can inspect, reuse, or study. +- Preserves reproducible notes and real workflow records instead of publishing only polished summaries. +- Keeps older Java and computer science learning materials available as an archive while shifting the active focus to AI-assisted development. +- Maintains public documentation, source files, and site structure in an open GitHub repository. + +## Public Repository Metrics + +Live repository metrics are available on GitHub: + +- Stars, forks, watchers, issues, and commit activity: +- Repository activity and recent commits: + +The project avoids hard-coding star and fork counts in this document because those numbers change over time. Reviewers should use the live GitHub metrics for the current values. + +## Recent Work + +Recent project work has focused on turning bestJavaer into cxuan-ai-labs: + +- Restructured the homepage around AI articles, AI resources, open-source works, development guidelines, and the archived bestJavaer material. +- Added categorized AI article indexes for Agent workflows, AI coding tools, model research, resources, industry notes, AI creation, and failure records. +- Added a card-based reading experience and previous/next article navigation for serialized reading. +- Added AI resource and works sections so readers can discover tools, examples, and maintained projects. +- Continued publishing practical AI coding notes, including Codex workflow usage, Agent Workflow Kit notes, token/cost observations, and real troubleshooting stories. + +## License + +This repository uses a dual-license model: + +- Documentation, articles, tutorials, images, and curated content are licensed under [CC BY-SA 4.0](./LICENSE). +- Code, scripts, tools, and software examples are licensed under [MIT](./LICENSE-MIT). + +If a subdirectory or file declares a separate license, that local declaration takes precedence. + +## Suggested Short Description + +bestJavaer / cxuan-ai-labs is an open-source AI coding workflow and developer education lab for Chinese-speaking developers. + +## Suggested Grant or Sponsorship Framing + +Support would help sustain open documentation, AI workflow research, resource curation, reproducible experiments, and maintenance for a Chinese-speaking developer audience. The project should be evaluated as an open AI coding workflow and developer education lab, not as a legacy Java repository. diff --git a/README.md b/README.md index df1e1bb..ed2a509 100644 --- a/README.md +++ b/README.md @@ -1,581 +1,116 @@ -# 成为一个更好的Java程序员 -这是一个成为更好的 `Java 程序员`的系列教程 - ->声明：这是完全手写的仓库，不严谨的地方请告知作者。 -> ->此项目无法和 Dubbo 等开源框架相提并论，请读者不要盲目崇拜，此项目只是作者近来的读书、学习笔记总结。如果你 `star` 一下我会很高兴的。 -> ->**本仓库仅供学习使用，商业用途请联系作者 (微信： lx252279279 )** - -![](https://img.shields.io/static/v1?label=bestjavaer&message=操作系统&color=blue)![](https://img.shields.io/static/v1?label=bestjavaer&message=计算机基础&color=)![](https://img.shields.io/static/v1?label=bestjavaer&message=计算机网络&color=yellowgreen) - -![](https://img.shields.io/static/v1?label=bestjavaer&message=Java基础&color=orange)![](https://img.shields.io/static/v1?label=bestjavaer&message=设计模式&color=success)![](https://img.shields.io/static/v1?label=bestjavaer&message=JVM&color=important)![](https://img.shields.io/static/v1?label=bestjavaer&message=Java并发&color=9cf) - -![](https://img.shields.io/static/v1?label=bestjavaer&message=Spring&color=blueviolet)![](https://img.shields.io/static/v1?label=bestjavaer&message=SpringBoot&color=informational)![](https://img.shields.io/static/v1?label=bestjavaer&message=Springcloud&color=ff69b4) - -![](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/mindmanage/bestjavaer.png) - -这是一个成为更好的程序员的系列教程内容涵盖 - -* [Java基础面试题](https://github.com/crisxuan/bestJavaer/wiki/Java%E9%9D%A2%E8%AF%95%E9%A2%98) -* [操作系统](https://github.com/crisxuan/bestJavaer#%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F%E7%B3%BB%E5%88%97) -* [计算机基础知识](https://github.com/crisxuan/bestJavaer#%E8%AE%A1%E7%AE%97%E6%9C%BA%E5%85%A5%E9%97%A8%E7%B3%BB%E5%88%97) -* [深入理解计算机系统](https://github.com/crisxuan/bestJavaer#%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%B3%BB%E7%BB%9F) -* [HTTP 系列](https://github.com/crisxuan/bestJavaer#http-%E7%B3%BB%E5%88%97) -* [汇编语言](https://github.com/crisxuan/bestJavaer#%E6%B1%87%E7%BC%96%E8%AF%AD%E8%A8%80) -* [C 语言](https://github.com/crisxuan/bestJavaer#c-%E8%AF%AD%E8%A8%80) -* [计算机网络](https://github.com/crisxuan/bestJavaer#%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C%E7%B3%BB%E5%88%97) -* [Java 基础教程](https://github.com/crisxuan/bestJavaer#java-%E5%9F%BA%E7%A1%80%E7%B3%BB%E5%88%97) -* [设计模式](https://github.com/crisxuan/bestJavaer#%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%E7%B3%BB%E5%88%97) -* [JVM](https://github.com/crisxuan/bestJavaer#jvm-%E7%B3%BB%E5%88%97) -* [并发](https://github.com/crisxuan/bestJavaer#%E5%B9%B6%E5%8F%91%E7%B3%BB%E5%88%97) -* [Spring 框架系列](https://github.com/crisxuan/bestJavaer#spring-%E7%B3%BB%E5%88%97) - * [Spring](https://github.com/crisxuan/bestJavaer#spring-%E7%B3%BB%E5%88%97) - * SpringMVC - * [SpringBoot](https://github.com/crisxuan/bestJavaer#springboot-%E7%B3%BB%E5%88%97) - * SpringCloud - * SpringCloud-Alibaba - * 等 -* [ORM 映射框架](https://github.com/crisxuan/bestJavaer#mybatis) - * [MyBatis](https://github.com/crisxuan/bestJavaer#mybatis) - * JPA - * Hibernate -* [ZooKeeper](https://github.com/crisxuan/bestJavaer#zookeeper-%E7%B3%BB%E5%88%97%E6%95%99%E7%A8%8B) -* [Kafka](https://github.com/crisxuan/bestJavaer#kafka-%E7%B3%BB%E5%88%97%E6%95%99%E7%A8%8B) -* [Redis](https://github.com/crisxuan/bestJavaer#redis-%E7%B3%BB%E5%88%97%E6%95%99%E7%A8%8B) -* [数据库](https://github.com/crisxuan/bestJavaer#mysql) - * [MySQL](https://github.com/crisxuan/bestJavaer#mysql) - * Oracle - * MogonDB - * PostgreSQL - * Memcached -* RabbitMQ -* Maven -* Git -* Nginx -* ELK -* Netty -* [Linux](https://github.com/crisxuan/bestJavaer#linux-%E7%B3%BB%E5%88%97) -* [算法](https://github.com/crisxuan/bestJavaer#%E7%AE%97%E6%B3%95) -* [实战篇](https://github.com/crisxuan/bestJavaer#%E5%AE%9E%E6%88%98%E7%AF%87) -* [思维导图](https://github.com/crisxuan/bestJavaer#%E6%80%9D%E7%BB%B4%E5%AF%BC%E5%9B%BE) -* [关于认知](https://github.com/crisxuan/bestJavaer#%E5%85%B3%E4%BA%8E%E8%AE%A4%E7%9F%A5) -* [电子书籍](https://github.com/crisxuan/bestJavaer#%E7%94%B5%E5%AD%90%E4%B9%A6%E7%B1%8D) -* [我的PDF](https://github.com/crisxuan/bestJavaer#%E6%88%91%E7%9A%84-pdf) -* [读者面试系列](https://github.com/crisxuan/bestJavaer#%E8%AF%BB%E8%80%85%E9%9D%A2%E8%AF%95%E7%B3%BB%E5%88%97) -* [面试题系列](https://github.com/crisxuan/bestJavaer#%E9%9D%A2%E8%AF%95%E9%A2%98%E7%B3%BB%E5%88%97) -* [优质 Github](https://github.com/crisxuan/bestJavaer#%E4%BC%98%E8%B4%A8-github-%E6%8E%A8%E8%8D%90) -* [每日一题计划](https://github.com/crisxuan/bestJavaer#%E6%AF%8F%E6%97%A5%E4%B8%80%E9%A2%98%E8%AE%A1%E5%88%92) - -也包括一些常见的面试题。 - -采用全面解析面试题的方式，让你去理解每个面试题的概念，而不只是单纯的背诵...... - -不多说，搞起。 - -## 操作系统系列 - -![](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/mindmanage/os-simple.png) - -* [硬核操作系统入门](https://github.com/crisxuan/bestJavaer/blob/master/operating-system/os-overview.md) -* [硬核操作系统之进程和线程](https://github.com/crisxuan/bestJavaer/blob/master/operating-system/os-processandthread.md) -* [硬核操作系统之内存管理](https://github.com/crisxuan/bestJavaer/blob/master/operating-system/os-rammanage.md) -* [硬核操作系统之文件系统](https://github.com/crisxuan/bestJavaer/blob/master/operating-system/os-filesystem.md) -* [硬核操作系统之输入输出](https://github.com/crisxuan/bestJavaer/blob/master/operating-system/os-inputoutput.md) -* [硬核操作系统之死锁](https://github.com/crisxuan/bestJavaer/blob/master/operating-system/os-deadlock.md) -* 硬核操作系统之虚拟化和云 -* 硬核操作系统之网络安全 -* 硬核操作系统之 Linux 系统研究 -* 硬核操作系统之 Windows8 系统研究 -* 硬核操作系统之 UNIX 系统研究 -* 硬核操作系统之 Android 系统研究 -* 硬核操作系统之如何设计操作系统 -* [操作系统核心概念](https://github.com/crisxuan/bestJavaer/blob/master/operating-system/os-importantconcept.md) -* [操作系统网站推荐](https://github.com/crisxuan/bestJavaer/blob/master/operating-system/os-recommand.md) -* [操作系统硬核回答](https://github.com/crisxuan/bestJavaer/blob/master/operating-system/os-howtolearn.md) -* [计算机基础常识](https://github.com/crisxuan/bestJavaer/blob/master/operating-system/computer-youshouldknow.md) - -## 计算机入门系列 - -![](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/mindmanage/computer-basic.png) - -* [程序员需要了解的硬核知识之 CPU](https://github.com/crisxuan/bestJavaer/blob/master/computer-basic/computer-cpu.md) -* [程序员需要了解的硬核知识之内存](https://github.com/crisxuan/bestJavaer/blob/master/computer-basic/computer-ram.md) -* [程序员需要了解的硬核知识之二进制](https://github.com/crisxuan/bestJavaer/blob/master/computer-basic/computer-binary.md) -* [程序员需要了解的硬核知识之磁盘](https://github.com/crisxuan/bestJavaer/blob/master/computer-basic/computer-disk.md) -* [程序员需要了解的硬核知识之压缩算法](https://github.com/crisxuan/bestJavaer/blob/master/computer-basic/computer-compression.md) -* [程序员需要了解的硬核知识之操作系统和应用](https://github.com/crisxuan/bestJavaer/blob/master/computer-basic/computer-osandapp.md) -* [程序员需要了解的硬核知识之操作系统入门](https://github.com/crisxuan/bestJavaer/blob/master/computer-basic/computer-os.md) -* [程序员需要了解的硬核知识之控制硬件](https://github.com/crisxuan/bestJavaer/blob/master/computer-basic/computer-disk.md) - -## 深入理解计算机系统 - -* [计算机系统入门概述](https://github.com/crisxuan/bestJavaer/blob/master/computersystem/csapp-basic.md) - -## HTTP 系列 - -![](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/mindmanage/http.png) - -* [全面了解 HTTP](https://github.com/crisxuan/bestJavaer/blob/master/http/http-basic.md) -* [HTTP 黑科技](https://github.com/crisxuan/bestJavaer/blob/master/http/http-advanced.md) -* [HTTP 核心概念](https://github.com/crisxuan/bestJavaer/blob/master/http/http-deepknow.md) -* [全面了解 HTTPS](https://github.com/crisxuan/bestJavaer/blob/master/http/http-https.md) -* [全面了解 Cookies、Session 和 Token](https://github.com/crisxuan/bestJavaer/blob/master/http/http-cookesessiontoken.md) - -## Linux 系列 - -* [Linux 开篇！！！](https://github.com/crisxuan/bestJavaer/blob/master/linux/linux-first.md) -* [Linux 进程和线程](https://github.com/crisxuan/bestJavaer/blob/master/linux/linux-processandthread.md) -* [Linux 内存管理](https://github.com/crisxuan/bestJavaer/blob/master/linux/linux-memroy-management.md) -* [Linux IO管理](https://github.com/crisxuan/bestJavaer/blob/master/linux/linux-io.md) -* [Linux 文件系统](https://github.com/crisxuan/bestJavaer/blob/master/linux/linux-file-system.md) - -## 计算机网络系列 - -* [计算机网络基础入门](https://github.com/crisxuan/bestJavaer/blob/master/network/network-basic.md) -* [你不得不知的计算机网络](https://github.com/crisxuan/bestJavaer/blob/master/network/network-center.md) -* [计算机网络应用层](https://github.com/crisxuan/bestJavaer/blob/master/network/network-appLevel.md) -* [计算机网络基础知识](https://github.com/crisxuan/bestJavaer/blob/master/network/computer-network-basic.md) -* [TCP/IP 基础知识](https://github.com/crisxuan/bestJavaer/blob/master/network/computer-network-tcpip.md) -* [计算机网络应用层协议](https://github.com/crisxuan/bestJavaer/blob/master/network/computer-application.md) +[English](./README.md) | [中文](./README.zh-CN.md) +
+ cxuan-ai-labs +
-## Java 基础系列 +# cxuan-ai-labs -![](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/mindmanage/java-basic.png) +An open-source lab for AI coding workflows, Agent experiments, and developer education. -* [Java 核心基础教程](https://github.com/crisxuan/bestJavaer/blob/master/java-basic/java-summary.md) -* [Java 代理](https://github.com/crisxuan/bestJavaer/blob/master/java-basic/java-proxy.md) -* [Java 反射](https://github.com/crisxuan/bestJavaer/blob/master/java-basic/java-reflect.md) -* [Java 集合](https://github.com/crisxuan/bestJavaer/blob/master/java-basic/java-collections.md) -* [String、StringBuffer 和 StringBuilder](https://github.com/crisxuan/bestJavaer/blob/master/java-basic/java-stringstringbufferstringbuilder.md) -* [深入理解 static 关键字](https://github.com/crisxuan/bestJavaer/blob/master/java-basic/java-static.md) -* [深入理解 Java 变量](https://github.com/crisxuan/bestJavaer/blob/master/java-basic/java-varaibles.md) -* [深入理解 final、finally、finalize](https://github.com/crisxuan/bestJavaer/blob/master/java-basic/java-final.md) -* [关于四种引用类型](https://github.com/crisxuan/bestJavaer/blob/master/java-basic/java-references.md) -* [Exception 和 Error 的区别](https://github.com/crisxuan/bestJavaer/blob/master/java-basic/java-exceptionanderror.md) -* [ArrayList 用法解析](https://github.com/crisxuan/bestJavaer/blob/master/java-basic/java-arraylist.md) -* [LinkedList 用法解析](https://github.com/crisxuan/bestJavaer/blob/master/java-basic/java-linkedlist.md) -* [for 、foreach 、iterator 三种遍历方式的比较](https://github.com/crisxuan/bestJavaer/blob/master/java-basic/java-forandforeach.md) -* [理解静态绑定与动态绑定](https://github.com/crisxuan/bestJavaer/blob/master/java-basic/java-staticbinding.md) -* [@SafeVarargs 使用说明](https://github.com/crisxuan/bestJavaer/blob/master/java-basic/javav-%40safavargs.md) -* [@SuppressWarnings 用法](https://github.com/crisxuan/bestJavaer/blob/master/java-basic/java-%40suppresswarnings.md) -* [Arrays.asList 解析](https://github.com/crisxuan/bestJavaer/blob/master/java-basic/java-arrays.asList.md) -* [Enum to String 一般用法](https://github.com/crisxuan/bestJavaer/blob/master/java-basic/java-enumtostring.md) -* [Comparable 和 Comparator的理解](https://github.com/crisxuan/bestJavaer/blob/master/java-basic/java-comparableandcomparator.md) -* [Effective Java - 覆盖 equals 时总要覆盖 hashCode](https://github.com/crisxuan/bestJavaer/blob/master/java-basic/effectivejava-equalsandhashcode.md) -* [Effective Java - 覆盖equals遵守的约定](https://github.com/crisxuan/bestJavaer/blob/master/java-basic/effectivejava-overrideequals.md) -* [Effective Java - 构造器私有、枚举和单例](https://github.com/crisxuan/bestJavaer/blob/master/java-basic/effectivejava-privateconstructor.md) -* [Effective Java - 静态方法与构造器](https://github.com/crisxuan/bestJavaer/blob/master/java-basic/effectivejava-staticandmethod.md) -* [Effective Java - try-with-resources 优先于try-finally](https://github.com/crisxuan/bestJavaer/blob/master/java-basic/effectivejava-try-with-resources.md) -* [学习 Java 网站推荐给你](https://github.com/crisxuan/bestJavaer/blob/master/java-basic/learn-java.md) +This repository documents practical AI-assisted development workflows, Agent experiments, tool evaluations, curated resources, reproducible notes, and real failure cases. It is not a news mirror and it is not a giant tutorial collection. The focus is on what was actually tried, what broke, what worked, and what can help developers build better workflows with AI. +
+ + Vercel OSS Program + +
+
+ Live Preview + · + AI Articles + · + AI Resources + · + Works & Open Source + · + Development Guidelines + · + Legacy Archive + · + Open Source Impact +
-### 源码分析 +## Start Here -[看完这篇 HashMap，和面试官扯皮就没问题了](https://github.com/crisxuan/bestJavaer/blob/master/java-basic/java-hashmap.md) +* [Grok Build Was Widely Criticized, Then Elon Open-Sourced It](./en/ai-articles/01-agent-and-coding/grok-build-was-criticized-then-open-sourced.md) -[AtomicXXX 的用法和实现原理](https://github.com/crisxuan/bestJavaer/blob/master/java-concurrent/java-atomicxxx.md) + 2026-07-22 +* [Qoder + Qwen 3.8: A Hands-On Test](./en/ai-articles/02-models-and-research/qoder-qwen-3-8-hands-on-test.md) -## 并发系列 + 2026-07-22 +* [Claude Design's System Prompt Leaked: The Essential Lessons](./en/ai-articles/02-models-and-research/claude-design-system-prompt-essential-lessons.md) - ![](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/mindmanage/java-concurrent.png) + 2026-07-22 +* [OpenAI Broke Through Hugging Face's Infrastructure](./en/ai-articles/04-industry-and-business/openai-broke-through-hugging-face-infrastructure.md) -* [简单认识并发](https://github.com/crisxuan/bestJavaer/blob/master/java-concurrent/java-concurrent-basic.md) -* [看完你就明白的锁系列之锁的状态](https://github.com/crisxuan/bestJavaer/blob/master/java-concurrent/java-lock-status.md) -* [看完你就明白的锁系列之乐观锁和悲观锁](https://github.com/crisxuan/bestJavaer/blob/master/java-concurrent/java-optimisticlock.md) -* [看完你就明白的锁系列之自旋锁](https://github.com/crisxuan/bestJavaer/blob/master/java-concurrent/java-spinlock.md) -* [锁系列汇总](https://github.com/crisxuan/bestJavaer/blob/master/java-concurrent/java-lock.md) + 2026-07-22 +* [Still Learning Loops? Graph Engineering Is Already Taking Off](./en/ai-articles/01-agent-and-coding/graph-engineering-is-already-taking-off.md) - + 2026-07-21 +* [OpenAI's Official Prompting Guide](./en/ai-articles/02-models-and-research/openai-official-prompting-guide.md) -### 源码分析 + 2026-07-20 -* [ReentrantLock 源码分析](https://github.com/crisxuan/bestJavaer/blob/master/java-concurrent/java-reentrantlock.md) -* [我花了 35 张图就为你让你了解 AQS](https://github.com/crisxuan/bestJavaer/blob/master/java-concurrent/java-aqs.md) -* [AtomicInteger 的用法和实现原理](https://github.com/crisxuan/bestJavaer/blob/master/java-concurrent/java-atomicInteger.md) +## Main Sections +* [AI Articles](./en/ai-articles/README.md) -## 设计模式系列 + Real AI tool usage, model observations, industry notes, failure records, and practical workflow writeups. +* [AI Resources](./en/ai-resources/README.md) -![](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/mindmanage/design-pattern.png) + GitHub projects, tools, and resources mentioned in the articles and worth bookmarking or trying. +* [Works & Open Source](./en/works/README.md) -* [设计模式基础入门](https://github.com/crisxuan/bestJavaer/blob/master/design-pattern/designpattern-basic.md) -* [我向面试官讲解了单例模式，他对我竖起了大拇指](https://github.com/crisxuan/bestJavaer/blob/master/design-pattern/designpattern-singlaton.md) + Products, tools, content projects, and open-source work maintained or built by the author. +* [Development Guidelines](./en/development-guidelines/README.md) -## JVM 系列 + Notes on AI coding, project maintenance, collaboration, and Agent workflow practices. +* [Legacy Archive](./archive-bestjavaer/README.md) -![](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/mindmanage/jvm.png) + The older bestJavaer materials covering Java, concurrency, JVM, operating systems, networking, MySQL, Spring, and interview topics. +## Recent Updates +* 2026-07-22 · [Grok Build Was Widely Criticized, Then Elon Open-Sourced It](./en/ai-articles/01-agent-and-coding/grok-build-was-criticized-then-open-sourced.md) +* 2026-07-22 · [Qoder + Qwen 3.8: A Hands-On Test](./en/ai-articles/02-models-and-research/qoder-qwen-3-8-hands-on-test.md) +* 2026-07-22 · [Claude Design's System Prompt Leaked: The Essential Lessons](./en/ai-articles/02-models-and-research/claude-design-system-prompt-essential-lessons.md) +* 2026-07-22 · [OpenAI Broke Through Hugging Face's Infrastructure](./en/ai-articles/04-industry-and-business/openai-broke-through-hugging-face-infrastructure.md) +* 2026-07-21 · [Still Learning Loops? Graph Engineering Is Already Taking Off](./en/ai-articles/01-agent-and-coding/graph-engineering-is-already-taking-off.md) +* 2026-07-20 · [OpenAI's Official Prompting Guide](./en/ai-articles/02-models-and-research/openai-official-prompting-guide.md) +* 2026-07-18 · [Kimi K3 Stole the Show](./en/ai-articles/02-models-and-research/kimi-k3-stole-the-show.md) +* 2026-07-18 · [LibTV Helped Me Get Past My Creative Anxiety](./en/ai-articles/05-ai-creation-and-media/libtv-helped-me-get-past-creative-anxiety.md) +* 2026-07-16 · [GPT-5.6 Ran rm -rf in the Background](./en/ai-articles/01-agent-and-coding/gpt-5-6-ran-rm-rf-in-the-background.md) -* Java 内存模型 -* 一个对象从 JVM 的角度是如何创建的 -* 垃圾回收理论介绍 -* 垃圾回收实战篇 -* 内存分配粗略与回收策略 -* 虚拟机性能监控工具与故障处理工具 -* 调优分析与实战 -* 类文件结构 -* 字节码指令介绍 -* 虚拟机类加载机制 -* 虚拟机字节码执行引擎 -* 程序编译与代码优化 +## Why Follow +* The content comes from real usage instead of rewritten product announcements. +* Failure paths and debugging notes are kept because, in the AI era, the troubleshooting process is often more valuable than the final answer. +* The resource pages are intentionally curated instead of trying to be exhaustive. +* The older bestJavaer materials remain available, while the active project direction moves toward AI tools, Agent workflows, and personal experiments. +## Build & SEO -## 汇编语言 +```bash +pnpm install +pnpm build +pnpm test +``` -* [从指令集的角度看汇编](https://github.com/crisxuan/bestJavaer/blob/master/assembly/assembly01.md) +The production build keeps the interactive Docsify experience and generates clean, crawlable HTML under `/articles/` and `/en/articles/`. It also rebuilds RSS feeds, `sitemap.xml`, canonical URLs, hreflang alternates, Open Graph metadata, and Article JSON-LD for every indexed article. -* [寄存器入门第一篇](https://github.com/crisxuan/bestJavaer/blob/master/assembly/assembly02.md) +## Legacy Content -## C 语言 +bestJavaer used to be a Chinese learning repository for Java developers, covering Java, concurrency, JVM, operating systems, computer networks, MySQL, Spring, interview topics, and related developer education material. -* [C 语言基础入门](https://github.com/crisxuan/bestJavaer/blob/master/cprograming/c-basic.md) +That material is not removed. It has been preserved in [archive-bestjavaer](./archive-bestjavaer/README.md). The current main line is now cxuan-ai-labs: AI coding workflows, Agent experiments, open-source resources, and practical developer education. +## License +This repository uses a dual-license model: +* Documentation, articles, tutorials, images, and curated content are licensed under [CC BY-SA 4.0](./LICENSE). +* Code, scripts, tools, and software examples are licensed under [MIT](./LICENSE-MIT). - -## MyBatis - -![](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/mindmanage/mybatis.png) - - - -* [MyBatis 基础搭建及架构概述](https://github.com/crisxuan/bestJavaer/blob/master/mybatis/mybatis-base.md) -* [MyBatis Configuration](https://github.com/crisxuan/bestJavaer/blob/master/mybatis/mybatis-configuration.md) -* [MyBatis 核心配置综述之Executor](https://github.com/crisxuan/bestJavaer/blob/master/mybatis/mybatis-executor.md) -* [MyBatis 核心配置综述之 StatementHandler](https://github.com/crisxuan/bestJavaer/blob/master/mybatis/mybatis-statmenthandler.md) -* [MyBatis 核心配置综述之 ParameterHandler](https://github.com/crisxuan/bestJavaer/blob/master/mybatis/mybatis-parameterhandler.md) -* [MyBatis 核心配置综述之 ResultSetHandler](https://github.com/crisxuan/bestJavaer/blob/master/mybatis/mybatis-resultsethandler.md) -* [MyBatis 一级缓存](https://github.com/crisxuan/bestJavaer/blob/master/mybatis/mybatis-firstcache.md) -* [MyBatis 二级缓存全详解](https://github.com/crisxuan/bestJavaer/blob/master/mybatis/mybatis-secondcache.md) -* [MyBatis 启动流程](https://github.com/crisxuan/bestJavaer/blob/master/mybatis/mybatis-howtostart.md) - - - -## MySQL - -![](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/mindmanage/mysql.png) - -* [MySQL 基础入门大全](https://github.com/crisxuan/bestJavaer/blob/master/mysql/mysql-basicall.md) - * [MySQL SQL 基本使用](https://github.com/crisxuan/bestJavaer/blob/master/mysql/mysql-sql.md) - * [MySQL 数据类型](https://github.com/crisxuan/bestJavaer/blob/master/mysql/mysql-datatype.md) - * [MySQL 运算符](https://github.com/crisxuan/bestJavaer/blob/master/mysql/mysql-operator.md) - * [MySQL 常用函数](https://github.com/crisxuan/bestJavaer/blob/master/mysql/mysql-func.md) -* [MySQL 开发](https://github.com/crisxuan/bestJavaer/blob/master/mysql/mysql-develop.md) - * [MySQL 存储引擎](https://github.com/crisxuan/bestJavaer/blob/master/mysql/mysql-storageengine.md) - * [MySQL 选择合适的数据类型](https://github.com/crisxuan/bestJavaer/blob/master/mysql/mysql-selectdatatype.md) - * [MySQL 字符集](https://github.com/crisxuan/bestJavaer/blob/master/mysql/mysql-charset.md) -* [SQL 进阶技巧](https://github.com/crisxuan/bestJavaer/blob/master/mysql/sql-improve.md) - -## Spring 系列 - -![](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/mindmanage/spring.png) - -* [Spring Bean 全解析](https://github.com/crisxuan/bestJavaer/blob/master/spring/spring-bean.md) -* [Spring AOP 扫盲](https://github.com/crisxuan/bestJavaer/blob/master/spring/spring-aop.md) -* [Spring 注解配置的基本要素](https://github.com/crisxuan/bestJavaer/blob/master/spring/spring-annotation.md) -* [Spring 中的 Null-Safety](https://github.com/crisxuan/bestJavaer/blob/master/spring/spring-null-safety.md) -* [Spring 中的验证、数据绑定和类型转换](https://github.com/crisxuan/bestJavaer/blob/master/spring/spring-databind.md) -* [PropertyPlaceholderConfigurer 用法](https://github.com/crisxuan/bestJavaer/blob/master/spring/spring-propertyplaceholderconfig.md) -* [BeanFactory 和 FactoryBean 的理解](https://github.com/crisxuan/bestJavaer/blob/master/spring/spring-beanfactoryandfactorybean.md) -* [BeanFactory 和 ApplicationContext 的异同](https://github.com/crisxuan/bestJavaer/blob/master/spring/spring-beanandapplication.md) -* [浅析PropertySource 基本使用](https://github.com/crisxuan/bestJavaer/blob/master/spring/spring-propertysource.md) -* [一文了解ConfigurationConditon 接口](https://github.com/crisxuan/bestJavaer/blob/master/spring/spring-configurationcondition.md) -* [@Configuration 全部用法](https://github.com/crisxuan/bestJavaer/blob/master/spring/spring-configuration.md) -* [Spring Resource 体系介绍](https://github.com/crisxuan/bestJavaer/blob/master/spring/spring-resource.md) - - - -### 源码分析 - - - -## SpringBoot 系列 - -waiting... - - - - - - - -## Kafka 系列教程 - -![](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/mindmanage/kafka-system.png) - -* [真的，Kafka 入门一篇就够了](https://github.com/crisxuan/bestJavaer/blob/master/kafka/kafka-basic.md) -* [你能说出这些 Kafka 的原理吗](https://github.com/crisxuan/bestJavaer/blob/master/kafka/kafka-deep.md) - - - -## Redis 系列教程 - -![](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/mindmanage/redis.png) - - - - - -## Nginx 系列教程 - -![](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/mindmanage/nginx.png) - - - - - -## ZooKeeper 系列教程 - -![](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/mindmanage/zookeeper.png) - -* [ZooKeeper 基础入门](https://github.com/crisxuan/bestJavaer/blob/master/zookeeper/zookeeper-basic.md) - - - - - - - -## 读者面试系列 - -* [今年面试这么难，到底如何进入大厂？](https://github.com/crisxuan/bestJavaer/blob/master/interview/interview-jingdong.md) -* [外包面试之旅](https://github.com/crisxuan/bestJavaer/blob/master/interview/interview-zhongruan.md) -* [京东面试之旅](https://github.com/crisxuan/bestJavaer/blob/master/interview/interview-jingdong-social.md) - -## 面试题系列 - -> 笔者非常痛恨网上那种什么面试题汇总等文章，无非就是各种百度拿了前几句滥竽充数一样，这种宣扬背诵的做法和高中老师教学生应付考试是一样的，侥幸心理、凡事图快的心理才助长了社会浮躁的风气。 -> -> 所以笔者励志把每道面试题从根源上助你理解 - -* [HTTP 高频面试题](https://github.com/crisxuan/bestJavaer/blob/master/interview-answer/http-interview.md) -* [用心为你写了 9 道 MySQL 面试题](https://github.com/crisxuan/bestJavaer/blob/master/interview-answer/mysql-interview.md) -* [Java 基础面试题汇总](https://github.com/crisxuan/bestJavaer/blob/master/interview-answer/java-basic-interview.md) - -* [操作系统面试题](https://github.com/crisxuan/bestJavaer/blob/master/operating-system/os-fiftyInterview.md) - -## 算法 - - - -## 实战篇 - - - - - -## 思维导图 - -* [更好的Java程序员](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/mindmanage/bestjavaer.png) -* [设计模式](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/mindmanage/design-pattern.png) -* [Java并发](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/mindmanage/java-concurrent.png) -* [JVM](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/mindmanage/jvm.png) -* [Kafka体系](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/mindmanage/kafka-system.png) -* [MyBatis体系](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/mindmanage/mybatis.png) -* [MySQL](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/mindmanage/mysql.png) -* [Nginx](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/mindmanage/nginx.png) -* [Redis](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/mindmanage/redis.png) -* [Spring](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/mindmanage/spring.png) -* [ZooKeeper](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/mindmanage/zookeeper.png) -* [程序员必备硬核知识](https://github.com/crisxuan/bestJavaer/blob/master/mindmanage/computer-basic.png) -* [现代操作系统](https://github.com/crisxuan/bestJavaer/blob/master/mindmanage/operating-system.png) -* [Java 基础核心总结](https://github.com/crisxuan/bestJavaer/blob/master/mindmanage/java-basic.png) -* [HTTP 核心总结](https://github.com/crisxuan/bestJavaer/blob/master/mindmanage/http.png) -* [Java.lang 包](https://github.com/crisxuan/bestJavaer/blob/master/mindmanage/java-lang.png) -* [I/O 流](https://github.com/crisxuan/bestJavaer/blob/master/mindmanage/java-io.png) -* [Session、Cookie 和 Token](https://github.com/crisxuan/bestJavaer/blob/master/mindmanage/sessioncookieandtoken.png) -* [锁的分类](https://github.com/crisxuan/bestJavaer/blob/master/mindmanage/java-lock.png) -* [AQS 框架](https://github.com/crisxuan/bestJavaer/blob/master/mindmanage/java-aqs.png) -* [Java.net 包](https://github.com/crisxuan/bestJavaer/blob/master/mindmanage/java-net.png) - -## 关于认知 - -* [2019 我是怎样熬过来的](https://github.com/crisxuan/bestJavaer/blob/master/aboutlife/cxuan-2019.md) -* [这是对我最大的认可和鼓励](https://github.com/crisxuan/bestJavaer/blob/master/aboutlife/cxuan-confidence.md) -* [1w+ 的心路历程](https://github.com/crisxuan/bestJavaer/blob/master/aboutlife/cxuan-1w%2B.md) -* [美国留学生关于教育、制度和考试的看法](https://github.com/crisxuan/bestJavaer/blob/master/aboutlife/american-life.md) -* [内心独白｜给粉蜜的一封信](https://github.com/crisxuan/bestJavaer/blob/master/aboutlife/cxuan-say.md) -* [给朋友们一些自信｜写于2019年4月](https://github.com/crisxuan/bestJavaer/blob/master/aboutlife/cxuan-bibi.md) -* [作者的一周](https://github.com/crisxuan/bestJavaer/blob/master/aboutlife/cxuan-oneweek.md) -* [bilibili 关于后浪有感](https://github.com/crisxuan/bestJavaer/blob/master/aboutlife/aboutbilibili.md) -* [电信诈骗](https://github.com/crisxuan/bestJavaer/blob/master/aboutlife/cxuan-deceive.md) -* [如何成为务实的程序员](https://github.com/crisxuan/bestJavaer/blob/master/aboutlife/good-programmer.md) -* [写给 25 岁的自己](https://github.com/crisxuan/bestJavaer/blob/master/aboutlife/cxuan-25yearsold.md) -* [面试官和面试者在同一个群里是怎样的体验](https://github.com/crisxuan/bestJavaer/blob/master/aboutlife/interviewer-story.md) - - - - - -## 关于职场 - - - - - - - -## 优质 Github 推荐 - -* [计算机自学 Github](https://github.com/keithnull/TeachYourselfCS-CN/blob/master/TeachYourselfCS-CN.md) -* [Crash Course 的 Github](https://github.com/1c7/Crash-Course-Computer-Science-Chinese) -* [JavaGuide 的 Github](https://github.com/Snailclimb/JavaGuide) - - - -## 每日一题计划 - -* 2020/06/02 [byte的取值范围是多少，怎么计算出来的](https://github.com/crisxuan/bestJavaer/wiki/byte%E7%9A%84%E5%8F%96%E5%80%BC%E8%8C%83%E5%9B%B4%E6%98%AF%E5%A4%9A%E5%B0%91%EF%BC%8C%E6%80%8E%E4%B9%88%E8%AE%A1%E7%AE%97%E5%87%BA%E6%9D%A5%E7%9A%84) - -* 2020/06/03 [HashMap 多线程操作导致死循环问题](https://github.com/crisxuan/bestJavaer/wiki/HashMap-%E5%A4%9A%E7%BA%BF%E7%A8%8B%E6%93%8D%E4%BD%9C%E5%AF%BC%E8%87%B4%E6%AD%BB%E5%BE%AA%E7%8E%AF%E9%97%AE%E9%A2%98) - -* 2020/06/04 [Integer 缓存池](https://github.com/crisxuan/bestJavaer/wiki/Integer-%E7%BC%93%E5%AD%98%E6%B1%A0) - -* 2020/06/05 [你知道 fail-fast 和 fail-safe 吗](https://github.com/crisxuan/bestJavaer/wiki/%E4%BD%A0%E7%9F%A5%E9%81%93-fail-fast-%E5%92%8C-fail-safe-%E5%90%97) - -* 2020/06/06 [Arrays.asList 获得的 List 应该注意什么](https://github.com/crisxuan/bestJavaer/wiki/Arrays.asList-%E8%8E%B7%E5%BE%97%E7%9A%84-List-%E5%BA%94%E8%AF%A5%E6%B3%A8%E6%84%8F%E4%BB%80%E4%B9%88) - -* 2020/06/07 [动态代理是基于什么原理](https://github.com/crisxuan/bestJavaer/wiki/%E5%8A%A8%E6%80%81%E4%BB%A3%E7%90%86%E6%98%AF%E5%9F%BA%E4%BA%8E%E4%BB%80%E4%B9%88%E5%8E%9F%E7%90%86) - -* 2020/06/08 [谈谈你用到的设计模式以及应用场景](https://github.com/crisxuan/bestJavaer/wiki/%E8%B0%88%E8%B0%88%E4%BD%A0%E7%9F%A5%E9%81%93%E7%9A%84%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F) - -* 2020/06/09 [谈一谈动态绑定和静态绑定](https://github.com/crisxuan/bestJavaer/wiki/%E9%9D%99%E6%80%81%E7%BB%91%E5%AE%9A%E5%92%8C%E5%8A%A8%E6%80%81%E7%BB%91%E5%AE%9A%E7%9A%84%E5%8C%BA%E5%88%AB) - -* 2020/06/10 [讲一讲 HashMap 中 put 的全过程](https://github.com/crisxuan/bestJavaer/wiki/%E8%AE%B2%E4%B8%80%E4%B8%8B-HashMap-put-%E7%9A%84%E8%BF%87%E7%A8%8B) - -* 2020/06/11 [谈一谈 Java 泛型和类型擦除](https://github.com/crisxuan/bestJavaer/wiki/Java-%E6%B3%9B%E5%9E%8B%E5%92%8C%E7%B1%BB%E5%9E%8B%E6%93%A6%E9%99%A4) - -* 2020/06/12 [聊一聊 MySQL 中的事务](https://github.com/crisxuan/bestJavaer/wiki/MySQL-%E4%BA%8B%E5%8A%A1%E5%9B%9B%E5%A4%A7%E7%89%B9%E6%80%A7) - -* 2020/06/13 请说出你知道的索引失效的几种情况 - -* 2020/06/15 聊一聊 Spring bean 的生命周期 - -* 2020/06/16 讲一讲你所知道的垃圾收集器以及实现原理 - -* 2020/06/17 谈一谈你所知道的 ThreadLocal - -* 2020/06/18 [聊一聊 InnoDB 与 MyISAM 的区别](https://github.com/crisxuan/bestJavaer/wiki/MySQL-%E5%B8%B8%E8%A7%81%E5%AD%98%E5%82%A8%E5%BC%95%E6%93%8E%E7%9A%84%E5%8C%BA%E5%88%AB) - -* 2020/06/19 Redis 缓存穿透、缓存雪崩和缓存击穿原因，以及解决方案 - -* 2020/06/20 [说一说进程通信有几种方式](https://github.com/crisxuan/bestJavaer/wiki/%E8%BF%9B%E7%A8%8B%E9%97%B4%E7%9A%84%E9%80%9A%E4%BF%A1%E6%96%B9%E5%BC%8F) - -* 2020/06/23 聊一聊你知道的 AQS - -* 2020/06/24 聊一聊两阶段加锁、死锁、活锁、通信间死锁、饥饿的概念 - -* 2020/06/29 地址栏输入 URL 发生了什么？ - -* 2020/07/01 [说一说 Java 中的几种引用类型，并分别详述各引用类型的特征](https://github.com/crisxuan/bestJavaer/wiki/%E5%BC%BA%E5%BC%95%E7%94%A8%E3%80%81%E8%8B%A5%E5%BC%95%E7%94%A8%E3%80%81%E8%99%9A%E5%BC%95%E7%94%A8%E5%92%8C%E5%B9%BB%E8%B1%A1%E5%BC%95%E7%94%A8%E7%9A%84%E5%8C%BA%E5%88%AB) - -* 2020/07/03 什么是 TIME-WAIT、为什么可以是三次挥手、为什么不能是两次握手、流量控制、滑动窗口、Nagle 算法、糊涂窗口综合症、拥塞控制、慢启动、拥塞避免、快重传、快恢复、长连接 VS 短连接 - -* 2020/07/04 说一说 你对 happen-before 规则的理解 - -* 2020/07/05 Object object = new Object() 谈谈你对这句话的理解? - -* 2020/07/06 说一说 DNS 的解析过程 - -* 2020/07/07 [什么是 DMA](https://github.com/crisxuan/bestJavaer/wiki/%E4%BB%80%E4%B9%88%E6%98%AF-DMA) - -* 2020/07/08 谈谈你对最左前缀原则的理解 - -* 2020/07/09 说一说你理解的计算机启动过程 - -* 2020/07/10 你们有什么意见可以给 cxuan 提出来，可以尽管提，可以私信可以群发 - -* 2020/07/13 你如何设置你的线程池参数 - -* 2020/08/19 聊一聊你知道的 final、finally 和 finalize。 - -* 2020/08/21 请详述一下 HTTP 中 Get/Post 区别 - -* 2020/08/24 [ThreadPoolExecutor 的构造方法都有哪些参数，分别代表什么意思？](https://github.com/crisxuan/bestJavaer/wiki/ThreadPoolExecutor-%E7%9A%84%E6%9E%84%E9%80%A0%E6%96%B9%E6%B3%95%E9%83%BD%E6%9C%89%E5%93%AA%E4%BA%9B%E5%8F%82%E6%95%B0%EF%BC%8C%E5%88%86%E5%88%AB%E4%BB%A3%E8%A1%A8%E4%BB%80%E4%B9%88%E6%84%8F%E6%80%9D%EF%BC%9F) - -* 2020/08/25 [synchronized 锁升级流程？](https://github.com/crisxuan/bestJavaer/wiki/synchronized-%E9%94%81%E5%8D%87%E7%BA%A7%E6%B5%81%E7%A8%8B) - -* 2020/08/26 [你项目中使用优雅的判空方式](https://github.com/crisxuan/bestJavaer/wiki/%E4%BD%A0%E9%A1%B9%E7%9B%AE%E4%B8%AD%E4%BD%BF%E7%94%A8%E4%BC%98%E9%9B%85%E7%9A%84%E5%88%A4%E7%A9%BA%E6%96%B9%E5%BC%8F) - -* 2020/08/27 [synchronized 和 ReentrantLock的区别？](https://github.com/crisxuan/bestJavaer/wiki/synchronized-%E5%92%8C-ReentrantLock%E7%9A%84%E5%8C%BA%E5%88%AB) - -* 2020/08/28 [CountDownLatch 和 CyclicBarrier 的区别](https://github.com/crisxuan/bestJavaer/wiki/CountDownLatch-%E5%92%8C-CyclicBarrier-%E7%9A%84%E5%8C%BA%E5%88%AB) - -* 2020/08/31 [索引的本质是什么？](https://github.com/crisxuan/bestJavaer/wiki/%E7%B4%A2%E5%BC%95%E7%9A%84%E6%9C%AC%E8%B4%A8%E6%98%AF%E4%BB%80%E4%B9%88%EF%BC%9F) - -* 2020/09/01 [解释下 Serialization 和 Deserialization](https://github.com/crisxuan/bestJavaer/wiki/%E8%A7%A3%E9%87%8A%E4%B8%8B-Serialization-%E5%92%8C-Deserialization) - -* 2020/09/02 MySQL 索引主要使用的数据结构有哪些。 - -* 2020/09/03 [描述一下 Java 动态代理的运行原理](https://github.com/crisxuan/bestJavaer/wiki/%E6%8F%8F%E8%BF%B0%E4%B8%80%E4%B8%8B-Java-%E5%8A%A8%E6%80%81%E4%BB%A3%E7%90%86%E7%9A%84%E8%BF%90%E8%A1%8C%E5%8E%9F%E7%90%86) - -* 2020/09/04 [为什么 Java 中只有值传递？为什么？](https://github.com/crisxuan/bestJavaer/wiki/%E6%8F%8F%E8%BF%B0%E4%B8%80%E4%B8%8B%E5%80%BC%E4%BC%A0%E9%80%92%E5%92%8C%E5%BC%95%E7%94%A8%E4%BC%A0%E9%80%92%E7%9A%84%E5%8C%BA%E5%88%AB) - -* 2020/09/07 [如果 redis 突然挂了 势必会同时对 mysql 造成很大压力，那么怎么避免呢](https://github.com/crisxuan/bestJavaer/wiki/%E5%A6%82%E6%9E%9C-redis-%E7%AA%81%E7%84%B6%E6%8C%82%E4%BA%86-%E5%8A%BF%E5%BF%85%E4%BC%9A%E5%90%8C%E6%97%B6%E5%AF%B9-mysql-%E9%80%A0%E6%88%90%E5%BE%88%E5%A4%A7%E5%8E%8B%E5%8A%9B%EF%BC%8C%E9%82%A3%E4%B9%88%E6%80%8E%E4%B9%88%E9%81%BF%E5%85%8D%E5%91%A2) - -* 2020/09/08 [在 Java 多线程中，notify 和 notifyall 的区别是？](https://github.com/crisxuan/bestJavaer/wiki/%E5%9C%A8-Java-%E5%A4%9A%E7%BA%BF%E7%A8%8B%E4%B8%AD%EF%BC%8Cnotify-%E5%92%8C-notifyall-%E7%9A%84%E5%8C%BA%E5%88%AB%E6%98%AF-%3F) - -* 2020/09/09 Java 线程共有几种状态，分别是如何转换的？ - -* 2020/09/10 [你知道 ARP 么，聊一聊 ARP 协议原理？](https://github.com/crisxuan/bestJavaer/wiki/%E4%BD%A0%E7%9F%A5%E9%81%93-ARP-%E4%B9%88%EF%BC%8C%E8%81%8A%E4%B8%80%E8%81%8A-ARP-%E5%8D%8F%E8%AE%AE%E5%8E%9F%E7%90%86%EF%BC%9F) - -* 2020/09/11 [MySQL 解释下 explain 显示的每个字断。](https://github.com/crisxuan/bestJavaer/wiki/MySQL-%E8%A7%A3%E9%87%8A%E4%B8%8B-explain-%E6%98%BE%E7%A4%BA%E7%9A%84%E6%AF%8F%E4%B8%AA%E5%AD%97%E6%96%AD) - -* 2020/09/14 [聊一聊 Liunx下的 I/O 模型](https://github.com/crisxuan/bestJavaer/wiki/%E8%81%8A%E4%B8%80%E8%81%8A-Liunx%E4%B8%8B%E7%9A%84-I-O-%E6%A8%A1%E5%9E%8B) - -* 2020/09/15 [说一说 Spring 事务的传播特性](https://github.com/crisxuan/bestJavaer/wiki/%E8%AF%B4%E4%B8%80%E8%AF%B4-Spring-%E4%BA%8B%E5%8A%A1%E7%9A%84%E4%BC%A0%E6%92%AD%E7%89%B9%E6%80%A7) - -* 2020/09/16 [TCP 协议如何来保证传输的可靠性？](https://github.com/crisxuan/bestJavaer/wiki/TCP-%E5%8D%8F%E8%AE%AE%E5%A6%82%E4%BD%95%E6%9D%A5%E4%BF%9D%E8%AF%81%E4%BC%A0%E8%BE%93%E7%9A%84%E5%8F%AF%E9%9D%A0%E6%80%A7%EF%BC%9F) - -* 2020/09/17 现有 25 匹马，5 个赛道，不用计时器，取前三名和前五名最少比赛次数是多少 - -* 2020/09/18 [说一说如何解决 ABA 问题？为什么能解决？解决思路是什么？](https://github.com/crisxuan/bestJavaer/wiki/%E8%AF%B4%E4%B8%80%E8%AF%B4%E5%A6%82%E4%BD%95%E8%A7%A3%E5%86%B3-ABA-%E9%97%AE%E9%A2%98%EF%BC%9F%E4%B8%BA%E4%BB%80%E4%B9%88%E8%83%BD%E8%A7%A3%E5%86%B3%EF%BC%9F%E8%A7%A3%E5%86%B3%E6%80%9D%E8%B7%AF%E6%98%AF%E4%BB%80%E4%B9%88%EF%BC%9F) - -* 2020/09/21 [为什么 TCP 建立连接需要三次握手，两次不行吗？（快手真题）](https://github.com/crisxuan/bestJavaer/wiki/%E4%B8%BA%E4%BB%80%E4%B9%88-TCP-%E5%BB%BA%E7%AB%8B%E8%BF%9E%E6%8E%A5%E9%9C%80%E8%A6%81%E4%B8%89%E6%AC%A1%E6%8F%A1%E6%89%8B%EF%BC%8C%E4%B8%A4%E6%AC%A1%E4%B8%8D%E8%A1%8C%E5%90%97%EF%BC%9F) - -* 2020/09/22 [Threadlocal 是否存在内存泄漏问题？](https://github.com/crisxuan/bestJavaer/wiki/Threadlocal-%E6%98%AF%E5%90%A6%E5%AD%98%E5%9C%A8%E5%86%85%E5%AD%98%E6%B3%84%E6%BC%8F%E9%97%AE%E9%A2%98%EF%BC%9F) - -* 2020/09/23 [聊一聊 线上 oom 的排查方案？](https://github.com/crisxuan/bestJavaer/wiki/%E8%81%8A%E4%B8%80%E8%81%8A-%E7%BA%BF%E4%B8%8A-oom-%E7%9A%84%E6%8E%92%E6%9F%A5%E6%96%B9%E6%A1%88%EF%BC%9F) - -* 2020/09/24 [请举出可能形成数据库死锁的原因、如何能避免死锁。](https://github.com/crisxuan/bestJavaer/wiki/%E8%AF%B7%E4%B8%BE%E5%87%BA%E5%8F%AF%E8%83%BD%E5%BD%A2%E6%88%90%E6%95%B0%E6%8D%AE%E5%BA%93%E6%AD%BB%E9%94%81%E7%9A%84%E5%8E%9F%E5%9B%A0%E3%80%81%E5%A6%82%E4%BD%95%E8%83%BD%E9%81%BF%E5%85%8D%E6%AD%BB%E9%94%81%E3%80%82) - -* 2020/09/27 [聊一聊 HTTPS 的工作流程。](https://github.com/crisxuan/bestJavaer/wiki/HTTPS-%E7%9A%84%E5%B7%A5%E4%BD%9C%E5%8E%9F%E7%90%86) - -* 2020/10/12 [简单说说你了解的类加载器，可以打破双亲委派么，怎么打破？](https://github.com/crisxuan/bestJavaer/wiki/%E7%AE%80%E5%8D%95%E8%AF%B4%E8%AF%B4%E4%BD%A0%E4%BA%86%E8%A7%A3%E7%9A%84%E7%B1%BB%E5%8A%A0%E8%BD%BD%E5%99%A8%EF%BC%8C%E5%8F%AF%E4%BB%A5%E6%89%93%E7%A0%B4%E5%8F%8C%E4%BA%B2%E5%A7%94%E6%B4%BE%E4%B9%88%EF%BC%8C%E6%80%8E%E4%B9%88%E6%89%93%E7%A0%B4%EF%BC%9F) - -* 2020/10/13 [聊一聊 SpringBoot 自动注入原理](https://github.com/crisxuan/bestJavaer/wiki/SpringBoot-%E8%87%AA%E5%8A%A8%E6%B3%A8%E5%85%A5%E5%8E%9F%E7%90%86) - -* 2020/10/14 [MySQL 的自增 ID 用完了怎么办？](https://github.com/crisxuan/bestJavaer/wiki/MySQL-%E7%9A%84%E8%87%AA%E5%A2%9E-ID-%E7%94%A8%E5%AE%8C%E4%BA%86%E6%80%8E%E4%B9%88%E5%8A%9E%EF%BC%9F) - -* 2020/10/15 聊一聊你所知道的垃圾收集器及其算法？ - -* 2020/10/16 什么是阻塞队列？阻塞队列的实现原理是什么？ - -* 2020/10/17 [count(1) 和 count(*) 的区别是怎样的？](https://github.com/crisxuan/bestJavaer/wiki/count(1)-%E5%92%8C-count(*)-%E7%9A%84%E5%8C%BA%E5%88%AB%E6%98%AF%E6%80%8E%E6%A0%B7%E7%9A%84%EF%BC%9F) - -* 2020/10/21 JVM GC 响应优先与吞吐优先的区别是什么? - -* 2020/10/22 [什么是一致性哈希？](https://github.com/crisxuan/bestJavaer/wiki/%E4%BB%80%E4%B9%88%E6%98%AF%E4%B8%80%E8%87%B4%E6%80%A7%E5%93%88%E5%B8%8C%EF%BC%9F) - -* 2020/10/26 [聊一聊 Redis 的几种删除策略。](https://github.com/crisxuan/bestJavaer/wiki/%E8%81%8A%E4%B8%80%E8%81%8A-Redis-%E7%9A%84%E5%87%A0%E7%A7%8D%E5%88%A0%E9%99%A4%E7%AD%96%E7%95%A5%E3%80%82) - -* 2020/10/27 [什么是数据库范式？聊一聊数据库都有哪些范式？](https://github.com/crisxuan/bestJavaer/wiki/%E4%BB%80%E4%B9%88%E6%98%AF%E6%95%B0%E6%8D%AE%E5%BA%93%E8%8C%83%E5%BC%8F%EF%BC%9F%E8%81%8A%E4%B8%80%E8%81%8A%E6%95%B0%E6%8D%AE%E5%BA%93%E9%83%BD%E6%9C%89%E5%93%AA%E4%BA%9B%E8%8C%83%E5%BC%8F%EF%BC%9F) - -* 2020/10/28 为什么 finally 一定会执行？ - - - -## 欢迎关注 - -欢迎关注作者的微信公众号 **Java建设者**，参加每日一题计划，关注公众号回复 `PDF` 给你分享作者硬肝的四本 PDF。 - -![](https://raw.githubusercontent.com/crisxuan/bestJavaer/master/qcode/javajianshecode.png) - - - +If a subdirectory or file declares a separate license, that local declaration takes precedence. diff --git a/README.zh-CN.md b/README.zh-CN.md new file mode 100644 index 0000000..9169bee --- /dev/null +++ b/README.zh-CN.md @@ -0,0 +1,116 @@ +[English](./README.md) | [中文](./README.zh-CN.md) + +
+ cxuan-ai-labs +
+ +# cxuan-ai-labs + +一个普通开发者在 AI 时代的真实折腾记录。 + +这里不做新闻搬运，也不做大而全教程。这里记录的是：真实用过的 AI 工具、踩过的坑、值得收藏的开源项目、AI coding 工作流，以及一些看起来不一定精致但确实折腾过的实验。 + +
+ + Vercel OSS Program + +
+ +
+ 在线预览 + · + AI 文章 + · + AI 资源 + · + 我的作品 & 开源项目 + · + 开发规约 + · + 旧内容归档 + · + 开源影响力说明 +
+ +## 先从这几篇开始 + +* [Grok Build 被众人唾骂，结果老马把它开源了](./ai-articles/01-agent-and-coding/Grok%20Build%20%E8%A2%AB%E4%BC%97%E4%BA%BA%E5%94%BE%E9%AA%82%EF%BC%8C%E7%BB%93%E6%9E%9C%E8%80%81%E9%A9%AC%E6%8A%8A%E5%AE%83%E5%BC%80%E6%BA%90%E4%BA%86.md) + + 2026-07-22 +* [Qoder + Qwen 3.8 实测](./ai-articles/02-models-and-research/Qoder%20%2B%20Qwen%203.8%20%E5%AE%9E%E6%B5%8B.md) + + 2026-07-22 +* [好家伙，继 Fable 5 系统提示词被扒之后，又一个 Claude 系统提示词被扒了。](./ai-articles/02-models-and-research/%E5%A5%BD%E5%AE%B6%E4%BC%99%EF%BC%8C%E7%BB%A7%20Fable%205%20%E7%B3%BB%E7%BB%9F%E6%8F%90%E7%A4%BA%E8%AF%8D%E8%A2%AB%E6%89%92%E4%B9%8B%E5%90%8E%EF%BC%8C%E5%8F%88%E4%B8%80%E4%B8%AA%20Claude%20%E7%B3%BB%E7%BB%9F%E6%8F%90%E7%A4%BA%E8%AF%8D%E8%A2%AB%E6%89%92%E4%BA%86%E3%80%82.md) + + 2026-07-22 +* [OpenAI 把 HuggingFace 打穿了](./ai-articles/04-industry-and-business/OpenAI%20%E6%8A%8A%20HuggingFace%20%E6%89%93%E7%A9%BF%E4%BA%86.md) + + 2026-07-22 +* [Loop 还没玩明白，Graph Engineering 又火了：说白了，就是给 Agent 组个团队](./ai-articles/01-agent-and-coding/Loop%20%E8%BF%98%E6%B2%A1%E7%8E%A9%E6%98%8E%E7%99%BD%EF%BC%8CGraph%20Engineering%20%E5%8F%88%E7%81%AB%E4%BA%86%EF%BC%9A%E8%AF%B4%E7%99%BD%E4%BA%86%EF%BC%8C%E5%B0%B1%E6%98%AF%E7%BB%99%20Agent%20%E7%BB%84%E4%B8%AA%E5%9B%A2%E9%98%9F.md) + + 2026-07-21 +* [OpenAI 官方提示词指南](./ai-articles/02-models-and-research/OpenAI%20%E5%AE%98%E6%96%B9%E6%8F%90%E7%A4%BA%E8%AF%8D%E6%8C%87%E5%8D%97.md) + + 2026-07-20 + +## 新主线 + +* [AI 文章](./ai-articles/README.md) + + 真实体验、工具观察、模型判断、行业变化和事故复盘。 +* [AI 资源](./ai-resources/README.md) + + 文章里提到过、值得点开收藏或试用的 GitHub 项目。 +* [我的作品 & 开源项目](./works/README.md) + + 自己做过、开源过或正在维护的产品、工具和内容项目。 +* [开发规约](./development-guidelines/README.md) + + AI coding、项目维护、协作流程和 Agent 工作流的沉淀。 +* [旧内容归档](./archive-bestjavaer/README.md) + + Java、并发、JVM、操作系统、网络、MySQL、Spring、面试题等旧 bestJavaer 内容继续保留。 + +## 最近更新 + +* 2026-07-22 · [Grok Build 被众人唾骂，结果老马把它开源了](./ai-articles/01-agent-and-coding/Grok%20Build%20%E8%A2%AB%E4%BC%97%E4%BA%BA%E5%94%BE%E9%AA%82%EF%BC%8C%E7%BB%93%E6%9E%9C%E8%80%81%E9%A9%AC%E6%8A%8A%E5%AE%83%E5%BC%80%E6%BA%90%E4%BA%86.md) +* 2026-07-22 · [Qoder + Qwen 3.8 实测](./ai-articles/02-models-and-research/Qoder%20%2B%20Qwen%203.8%20%E5%AE%9E%E6%B5%8B.md) +* 2026-07-22 · [好家伙，继 Fable 5 系统提示词被扒之后，又一个 Claude 系统提示词被扒了。](./ai-articles/02-models-and-research/%E5%A5%BD%E5%AE%B6%E4%BC%99%EF%BC%8C%E7%BB%A7%20Fable%205%20%E7%B3%BB%E7%BB%9F%E6%8F%90%E7%A4%BA%E8%AF%8D%E8%A2%AB%E6%89%92%E4%B9%8B%E5%90%8E%EF%BC%8C%E5%8F%88%E4%B8%80%E4%B8%AA%20Claude%20%E7%B3%BB%E7%BB%9F%E6%8F%90%E7%A4%BA%E8%AF%8D%E8%A2%AB%E6%89%92%E4%BA%86%E3%80%82.md) +* 2026-07-22 · [OpenAI 把 HuggingFace 打穿了](./ai-articles/04-industry-and-business/OpenAI%20%E6%8A%8A%20HuggingFace%20%E6%89%93%E7%A9%BF%E4%BA%86.md) +* 2026-07-21 · [Loop 还没玩明白，Graph Engineering 又火了：说白了，就是给 Agent 组个团队](./ai-articles/01-agent-and-coding/Loop%20%E8%BF%98%E6%B2%A1%E7%8E%A9%E6%98%8E%E7%99%BD%EF%BC%8CGraph%20Engineering%20%E5%8F%88%E7%81%AB%E4%BA%86%EF%BC%9A%E8%AF%B4%E7%99%BD%E4%BA%86%EF%BC%8C%E5%B0%B1%E6%98%AF%E7%BB%99%20Agent%20%E7%BB%84%E4%B8%AA%E5%9B%A2%E9%98%9F.md) +* 2026-07-20 · [OpenAI 官方提示词指南](./ai-articles/02-models-and-research/OpenAI%20%E5%AE%98%E6%96%B9%E6%8F%90%E7%A4%BA%E8%AF%8D%E6%8C%87%E5%8D%97.md) +* 2026-07-18 · [周三跟大家说的一些模型可能要发布，结果今天 Kimi 就炸场了。](./ai-articles/02-models-and-research/%E5%91%A8%E4%B8%89%E8%B7%9F%E5%A4%A7%E5%AE%B6%E8%AF%B4%E7%9A%84%E4%B8%80%E4%BA%9B%E6%A8%A1%E5%9E%8B%E5%8F%AF%E8%83%BD%E8%A6%81%E5%8F%91%E5%B8%83%EF%BC%8C%E7%BB%93%E6%9E%9C%E4%BB%8A%E5%A4%A9%20Kimi%20%E5%B0%B1%E7%82%B8%E5%9C%BA%E4%BA%86%E3%80%82.md) +* 2026-07-18 · [LibTV](./ai-articles/05-ai-creation-and-media/LibTV.md) +* 2026-07-16 · [离谱，GPT-5.6 竟然在后台执行了 rm -rf](./ai-articles/01-agent-and-coding/%E7%A6%BB%E8%B0%B1%EF%BC%8CGPT-5.6%20%E7%AB%9F%E7%84%B6%E5%9C%A8%E5%90%8E%E5%8F%B0%E6%89%A7%E8%A1%8C%E4%BA%86%20rm%20-rf.md) + +## 为什么值得关注 + +* 这里的内容来自真实使用，不是把发布会信息重新洗一遍。 +* 文章会保留“踩坑”和“失败路径”，因为 AI 时代最值钱的往往不是结论，而是排错过程。 +* 资源页不追求大而全，只收适合读者顺手收藏、试用或作为参考的项目。 +* 旧 bestJavaer 的内容不会丢，新内容会继续向 AI 工具、Agent 工作流和个人实验转移。 + +## 构建与 SEO + +```bash +pnpm install +pnpm build +pnpm test +``` + +生产构建会保留现有 Docsify 动态阅读体验，同时在 `/articles/` 与 `/en/articles/` 输出可直接抓取的完整 HTML，并为每篇文章生成 RSS、Sitemap、Canonical、hreflang、Open Graph 和 Article JSON-LD。 + +## 旧内容 + +以前，这里是写给 Java 程序员的系统学习仓库：Java、并发、JVM、操作系统、计算机网络、MySQL、Spring、面试题，能写的都写过一点。 + +现在，这个仓库的新主线会慢慢转向 AI。旧内容已经整体归档到 [archive-bestjavaer](./archive-bestjavaer/README.md)，仍然可以继续阅读。 + +## 开源协议 + +本仓库采用双协议声明： + +* 文档、文章、教程、图片、资源整理等内容使用 [CC BY-SA 4.0](./LICENSE) 协议。 +* 代码、脚本、工具、示例程序等软件部分使用 [MIT](./LICENSE-MIT) 协议。 + +如果某个子目录或文件单独声明了许可证，以该子目录或文件的声明为准。 diff --git a/_404.en.md b/_404.en.md new file mode 100644 index 0000000..6b1c09d --- /dev/null +++ b/_404.en.md @@ -0,0 +1,6 @@ +
+

404 / LOST SIGNAL

+

Page not found

+

This address may have moved, been renamed, or never existed. Return home or continue browsing the AI articles.

+

Back homeBrowse articles

+
diff --git a/_404.md b/_404.md new file mode 100644 index 0000000..57c4918 --- /dev/null +++ b/_404.md @@ -0,0 +1,6 @@ +
+

404 / LOST SIGNAL

+

页面没有找到

+

这个地址可能已经移动、改名，或者从未存在。你可以回到首页，或继续浏览 AI 文章。

+

返回首页浏览文章

+
diff --git a/_navbar.md b/_navbar.md new file mode 100644 index 0000000..879158b --- /dev/null +++ b/_navbar.md @@ -0,0 +1,10 @@ +* Home +* 中文 +* AI Articles +* AI Resources +* Development Guidelines +* Legacy Archive +* GitHub + * GitHub Profile + * Repository + * Works & Open Source diff --git a/_sidebar.md b/_sidebar.md new file mode 100644 index 0000000..2b0b766 --- /dev/null +++ b/_sidebar.md @@ -0,0 +1,17 @@ +* Home +* Chinese README + +* Main Track + * AI Articles + * AI Agent & Coding Tools + * Models, Research & Prompt + * Tools, Resources & Workbench + * Industry, Companies & Business + * AI Creation & Media + * Notes, Essays & Incidents + * AI Resources + * Works & Open Source + * Development Guidelines + +* Legacy Archive + * archive-bestjavaer diff --git a/aboutlife/cxuan-bibi.md b/aboutlife/cxuan-bibi.md deleted file mode 100644 index ab4ed42..0000000 --- a/aboutlife/cxuan-bibi.md +++ /dev/null @@ -1,18 +0,0 @@ -# 给朋友们一些自信 - -​ 大家好，我是Java建设者的号主，姑且自称cxuan吧，起这个名字的目的呢，缘由是我大学是学校足球队的，经常踢球，喜欢C罗，然后后面是自己的后缀。那么写此文的目的呢，是这样，时间过的很快，马上就要毕业两年，从事软件开发这个行业也有一段时间了，也有了自己的一些感悟，这些感悟可能比较矫情，也可能比较装逼，也可(应)能(该)比较(很)low逼，但是确确实实是我自己的写照。 - -​ 我并不是大佬，相反，我只是一条鱼，并且加了不少盐。我毕业于2017年，是一个再普通不过的三本院校(现在好像没有三本了)，大学混剂了四年，吃喝x赌抽，除了把妹之外样样精通，我总结一点不会把妹的原因：就是太老实了，心眼太好。嗯……………其实我是因为有对象…….希望不会被打。大学四年，经常性的不上课，逃课踢球，挂科都有我的身影，当时的想法就是年轻啊，年轻好啊。什么都要体验一把，回想起来自己才没有白过！现在回想起来，确实都体验到了，但是确实浪费了四年，准确的说，是三年甩个尾。就如同人始终逃不过真香定律一样，我刚进入大学校门就明确发誓我这辈子永不搞it，不做软件！！！呵呵呵呵呵哒。大四我面对突入其来的就业压力和自己渺茫的前途竟然不慌，我参加的校企合作的培训完全竟然完全是对象的劝导，可能没有那一晚上的劝导，也就不会多我这一个和广大程序员们抢工作的机会了。是不是感觉很戏谑，这么搞笑的么，还真是这么回事，但是一如软件深似海，从此头发是路人。 - -​ 我这里想给朋友们一些自信，是我觉得你们的出身和智商都会比我强很多。首先来说说出身，破破烂烂的三本院校是大部分高中生高考随便一考就能上的吧，但是却是我"努力很长时间"才换来的。说出来你们可能不信，我真的是属于死学的那种人，就是看书看不进去，看10分钟愣时20分钟的这种，而且也不愿意睡觉，彷佛睡觉就是我的敌人一样，每天的作息一直都是12点睡，6点起，这个作息也许是大部分考研朋友们最喜欢的作息了。这六个小时的作息习惯我一直延续到现在了。高中的时候，我可能没有见过比我再努力的了，但是奈何教育氛围受限，考成这样也是大环境所致（我也不是那种牛逼，任环境再怎么差，自己仍旧有强烈的自信觉得自己能上本一的这类傲娇的人）。到了大学更不会学习，那时的想法就是：上大学怎么可能用来学习呢？现在觉得当时还受到社会那种学习无用论的影响，low到自己认为天生我材必有用，我不学习照样是人精。现在的我认为__大学真的很重要，你在大学的习惯有很大概率决定你一生的习惯，你走过的路一定是你若干年后的真实写照。__ - -​ 大学时期自己做的主要几个事情：混课、看妹子、踢球、健身、喝酒、吹牛逼。妥妥的是一个混混大学生能做的所有的事情了。混课，上课从来不听讲，一直都是最后一排，做到最前面会心里很慌，一方面是怕人被发现自己在干什么，一方面也不想这么不尊重老师，其实说到尊师这件事情我一直认为我做的是比较好的，我从小学到大学一直都比较尊重老师，即使我并不喜欢这个老师，也不管这个老师是对我好还是对我不好，我都会尊重他。也许我认为几乎所有的除了985、211以下的大学都是这种上课状态，同时学习无用论还对我产生了影响，所以我从来都不听课，若干年后去了一趟南京大学找了一趟某皓才真正知道大学的氛围应该是什么样，大学课堂应该是什么样的。看妹子这件事情讲来就比较尴尬，这也算是男人的本性吧，你可以看，你也可以意淫，但是你不能去做啊。这件事情性质就不一样了。想法和行动是不能相比的。现在的女孩子们发育都比较早，而且也慢慢的越来越爱美，再加上化妆品和美颜软件的流行，身材再好一些，简直就是大部分人的视奸对象，我说的这些话也可能上午说的下午我女友就和我生气了但是我还得说啊，这话憋肚子里多难受啊，美女可以看看，但是男人不能天天围着美女转啊，还是需要有自己的兴趣和爱好，有自己的价值和判断的啊，好了这个话题点到为止了，大部分朋友都有自己的一套价值和判断。踢球这件事情说来就比较爽，大学踢球就跟疯了一样，几乎天天踢，有人找就踢，不管人多人少，没人也自己踢，想踢就踢，脚痒痒就下去自己练球，同时自己还有过将近两年的健身经验，虽然现在已沦为废柴，但是自己当时对自己的身形还是很满意的，甚至自己有过想专业从事健身方向的想法和行动。再来说说喝酒和吹牛逼这两件事，可以和为一件事儿来说。喝酒能让会吹牛逼的人上天，也能让不愿意吹牛逼的人吹牛逼。我们大学宿舍四人间就住了三个人(这个真是修来的福气)，环境很好，也巧来入学的时候周围都是大三的学长，晚上睡觉经常能听见宿舍叮咣叮咣的声音，早上保洁大妈打扫的时候也是，全是啤酒瓶的声音，偶尔还能遇到各种呕吐物，那时候我也经常聚餐，和球队的人一起，晚上买点酒再要点小零食，搁楼道拐角处就开始吹牛逼，一个个都觉得自己是楼道老大，经常吹牛逼谁又做了哪些牛逼的事儿，又搞了几个妹子，炫耀自己在大学的权利，但是球队的人都比较直，比较随性，这种牛逼吹的不让人反感，应该也算是投对了圈子。不像是某学生会或者跟心眼多的人聚餐，太累，那种一个人说话别人都得静静地听，讲究各种餐桌礼仪，酒桌文化，还有潜规则和套路，真的太心累。现在的社会环境不同以往，现在大家都讲究尊重和舒服，不论你多么牛逼或者穷困，你是我的朋友我就关心你，做事情都会想着你，我觉得这是正确的价值观，而且我不喜欢舔狗，我喜欢价值观的契合和思想的深度，我不排斥吹牛逼哈哈哈哈。 - -​ 所以你看到这里，觉得我的大学生活是不是过的浑浑噩噩？如果和我一样甚至还不如我的话，那么朋友，你需要有一些危机意识了，因为21世纪最贵的是人才，不是不学无用论就能大行其道，仗着自己有点权利就能横行炫耀的年代了，现在崩一个人设多么的简单！如果你用自己的一点权力能够获利的话，别太自满，那是因为还没有人整你或者还没来得及整你。如果你过的比我好，甚至看到这觉的你瞧不起我的话，也别太骄傲，这毕竟是走下坡路的表现；如果你能和我产生强烈的共鸣，那么我们能交上朋友。如果再让我选择回到大学，我能让自己再踢球之余，把自己学到吐！ - -​ 这里再要谈一谈大佬这件事情，首先我认为大佬一定是那种你和他聊天，发现他是一个无底洞的那种人，就是你和他聊天，很愉悦，能够使自己思想受到淘洗，信息量大能让你产生冥思，从而觉得世界彷佛很简单了起来。而不是单纯的告诉你这件事情怎么做那件事情怎么做，这样的人顶多算是前辈，他不过是比你多了一些工作经验，知道的比你多而已。所以，我根本就不是大佬。而且我认为大佬这个词会让人产生压力感，就比如你对别人说大佬帮我看个问题吧，就好像你必须要帮他解决这个问题，解决不完你就有愧对这个词一样。而且我认为大佬这个词一定是经历了你所经历的一切，但是依然保持对生活的热情，对事业和技术的热枕，不会因为生活的压力和不如意从而变得麻木不仁。而且大佬这个词只应该存在于想象中，说出来就会变了味道。 - -​ 说实话现在真的很羡慕现在的在校大学生了，非常自由，拥有自己的个性，而且又处于互联网的浪潮之中，真的，这个世界会很美好的。从现在开始，去多学一些东西吧，学习是一件逆人性的事情，刚开始学习会非常痛苦，我也一样。__你就想吧，一个从坐十分钟就会浑身不自在，天天吹牛逼的人变到现在经常没人打扰会坐上一整天甚至一晚上，闲暇之余只想学习，动都会感觉到累，沉默寡言的人需要付出多少辛苦和汗水？__我这种秀智商下限的人都可以，那么我相信你也可以。不要再把大把的时间都放在搞了多少个女友，谁的对象好看，能喝多少酒，爱慕虚荣和互相攀比上面了，这不是你吹嘘的资本。 - -​ 没逼逼够，➕lx252279279 继续逼逼？ - diff --git a/ai-articles/01-agent-and-coding/2026 AI Agent.md b/ai-articles/01-agent-and-coding/2026 AI Agent.md new file mode 100644 index 0000000..657c0c2 --- /dev/null +++ b/ai-articles/01-agent-and-coding/2026 AI Agent.md @@ -0,0 +1,354 @@ +# AI Agent 2026：技术趋势、企业落地与开发者核心竞争力 + +> 日期：2026-04-07 + +## 引言：从“会说话”到“会办事” + +还记得那种感觉吗？刚接触 ChatGPT那会儿，觉得这玩意有点意思，什么都能聊，但同时又觉得这玩意回答的驴唇不对马嘴，甚至有的时候能给你把黑的说成白的。但用久了你会发现一个更基本的问题——它很会说，但不太会做。你让它写个方案，它给你洋洋洒洒几千字；你让它真正帮你把事情办了，它就歇菜了。 + +早期的通用大模型只有**生成能力**，缺少自主拆解任务、持续调用工具、闭环落地的能力。但2026 年的 AI Agent，会把能说变成闭环干完一整套程序流程。 + +CB Insights的CEO最近有个说法很到位：“AI Agent在短短2年内已从实验品转变为企业的优先事项。我看到自2023年以来，在财报电话会议上提及Agent的次数增加了10倍。这种速度是我前所未见的。” + +82%的企业表示将在未来12个月内把AI智能体应用于客户支持领域。在1500多个科技细分赛道里，2025年按投融资交易数量排名前10位中，有5个与AI Agent直接相关。换句话说，最火热的投资热点，一半来自 Agent 概念。 + +image-20260406200827727 + +这不是泡沫，是生产力的范式转移。 + +今天这篇文章，我将从技术原理、企业落地、开发者实践三个维度，带你看清楚2026年AI Agent的真实面貌。 + +--- + +## 一、技术原理：高效智能体的三大支柱 + +把AI Agent模拟成一个人类员工会更直观。它需要什么能力？理解任务、记住上下文、调用工具、规划步骤、执行落地。这对应的技术核心就是三个维度：**记忆管理**、**工具学习**、**规划推理**。 + +### 记忆管理：智能体的“脑子” + +为什么你的AI Agent总像金鱼一样记不住事？因为记忆管理没做好。 + +智能体的记忆分为两层： + +**工作记忆（Working Memory）**，相当于人类的工作台。当前正在处理的任务信息都堆在这儿。问题是上下文窗口有限，你不能让Agent把整部《红楼梦》都塞进去。所以出现了两种优化思路： + +- **文本压缩**：行业主流会用长文本摘要、轻量化记忆压缩方案优化存储。 +- **潜在记忆**：部分方案会通过优化 KV 缓存加速上下文读取，真正长期留存的隐形记忆，还是靠摘要归档 + 向量库实现。 + +**外部记忆**，相当于智能体的“硬盘”。模型本身处理不了的东西，扔到外面存着。最常见的是向量数据库，用语义相似度检索；也有用知识图谱的，把实体关系组织起来，支持多跳推理。 + +image-20260406201723369 + +记忆管理还有个关键问题：**遗忘策略**。记忆会无限增长，必须有淘汰机制。 + +规则驱动的方式成本低，但可能误删重要信息；LLM驱动的方式自适应，但会增加计算开销。混合策略是目前的主流——用规则判断什么时候该触发合并，再用LLM执行具体的压缩操作。 + +### 工具学习：智能体的“手脚” + +AI Agent不只是一个语言模型，它需要真正做事。这就涉及工具调用能力。 + +工具学习的演进很有意思。早期的方式很简单粗暴——给模型一份工具列表，让它自己决定调用哪个。问题是模型经常乱点鸳鸯谱，明明该查数据库的，它给你调用了个天气API。 + +现在的方案更系统化。上海AI Lab和复旦等高校联合发布的综述，提出了**工具学习的三阶段框架**： + +- **工具发现**：Agent能感知自己有哪些可用工具。这需要良好的工具注册和描述机制。 +- **工具选择**：给定任务，Agent能选出最合适的工具组合。这考验的是模型的任务理解能力。 +- **工具对齐**：Agent知道怎么正确调用工具，参数怎么填，返回结果怎么用。 + +![image-20260407101537164](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260407101537164.png) + + +2026年值得关注的新协议是**MCP（Model Context Protocol）**。这是Anthropic主导的开放标准，你可以把它理解为AI模型的“USB接口”——不管什么型号的AI，只要支持MCP，就能插上各种工具和数据源。 + +MCP的核心优势是标准化。一个MCP服务器开发出来，所有支持MCP的AI客户端都能用。双向通信能力让服务器能主动推送更新，这对实时性要求高的场景很重要。 + +### 规划推理：智能体的“思维” + +把大象装进冰箱分几步？人类知道是三步。AI Agent需要学会这种任务分解能力。 + +规划能力决定了一个Agent能处理多复杂的任务。主流方案包括： + +- **思维链（Chain of Thought）**：让模型把推理过程显式说出来，一步一步来。 +- **ReAct**：在推理和行动之间切换，根据执行结果调整下一步计划。 +- **树状思维（Tree of Thought）**：探索多条可能的路径，选取最优解。 + +image-20260406201044264 + + +但规划能力最大的瓶颈不是“想不想得到”，而是**成本**。相比单轮LLM对话，Agent由于递归调用记忆、工具和规划，导致了指数级的资源消耗。有个很形象的说法：OpenClaw这种Agent工具，让很多人“玩了一星期，几百块钱没了”。 + +所以效率优化成了关键课题。核心思路是：在固定成本下最大化任务成功率，或在相同效果下最小化成本。 + +--- + +## 二、AI Agent正在席卷一切 + +### 三大 Agent 类型：各有各的地盘 + +当前 AI Agent 江湖主要有三种类型，各自占据不同的应用场景。 + +image-20260406182542922 + +#### Browser Agent：网页自动化的高手 + +Browser Agent 的核心能力是**自动操控网页完成跨平台任务**。它能像人一样看懂网页界面、理解按钮和输入框的含义、然后执行点击、填写、提交等操作。 + +典型的应用场景包括：自动填写复杂的网页表单、从多个网站聚合数据、批量处理需要人工操作的重复性网页任务。想象一下，你再也不用手动在各种后台系统里点点点，Browser Agent 可以帮你把那些机械化的网页操作全部自动化。 + +#### Coding Agent：独立完成从需求到部署的全流程 + +Coding Agent 是开发者群体里最火热的赛道。它能独立完成从需求分析、代码编写、测试验证到部署上线的完整开发流程。 + +现在的 Coding Agent 已经能做到：理解产品经理写的需求文档、生成符合项目规范的代码、自动编写测试用例并运行、把代码部署到云环境、甚至自动排查和修复线上问题。一个三人团队配上几个 Coding Agent，产出可能抵得上以前十个人的传统开发团队。 + +Cursor、Windsurf、GitHub Copilot Workspace 、Trae、Qoder 这些产品，大家应该不陌生了。 + +#### Multi-Agent Team：多角色协作解决复杂问题 + +前两种 Agent 都是单打独斗，而 Multi-Agent Team 则是让多个 Agent 组成团队，通过角色分工协作解决复杂问题。 + +比如一个软件开发项目，可能有一个 Agent 负责架构设计、一个负责前端开发、一个负责后端开发、一个负责测试、一个负责部署，Agent 之间通过 `A2A（Agent to Agent）`协议互相通信、协调进度、共享信息。 + +这种模式的牛逼之处在于，它可以突破单个 Agent 的能力上限——复杂任务被拆解成子任务，每个子任务由最擅长的 Agent 执行，最后汇总成完整结果。 + +### 数字说话：落地速度比预想的快 + +麦肯锡2025年11月发布的调研显示，全球78%的组织已在日常运营中使用某种AI工具，其中85%已将AI Agent集成至至少一项工作流程。这意味着AI Agent已经从实验性工具进入企业级实用阶段。 + +具体数字更让人惊讶： + +- 23%的企业已在企业内部至少一个业务职能中**规模化部署**Agentic AI系统 +- 39%的企业处于实验阶段，多数规模化部署覆盖1-2个职能 +- 在金融、电商领域，AI Agent渗透率超过30% +- 在落地速度相对较慢的制造业，也快达到20% + + +2025年，Salesforce的AI Agent创建与部署增长了119%，完成的行动量环比增长约80%月增率。 + +中商产业研究院的数据更能说明问题：2025年全球AI智能体市场规模约113亿美元，2024年约为51亿美元——一年翻倍多。中国市场的增速更快，2025年约69亿元，2024年约28.73亿元。 + +### 行业渗透：从客服到全链路 + +CB Insights报告指出，2026年AI Agent将深入企业工作流，行业专属应用加速落地。 + +**客户服务**是当前最成熟的应用场景。82%的企业计划在未来12个月内将AI智能体应用于客户支持，这不是说着玩的。语音AI智能体将能够处理复杂的对话，实现零人工干预。Meta在2025年接连收购语音AI初创企业，已经释放出行业加速整合的信号。 + +**软件开发**是最先被颠覆的领域。Cursor年收入5亿美元，2022年才成立；Lovable和Mercor年收入均达1亿美元，2023年才成立。这种成长速度，传统软件公司想都不敢想。 + +**金融、医疗、零售**等行业也在快速跟进。医疗领域聚焦影像识别、报告生成等辅助诊断场景，用户复购率超过40%。 + +image-20260406220416173 + +### 从Copilot到Autonomous Agent + +当前的AI Agent，大多数还处于“副驾驶”阶段——在受限环境中运行，利用结构化工作流和“护栏”来完成特定目标，同时保留一些决策控制。 + +但趋势很明确：基础模型能力在提升，Agent的自主性也在增强。 + +Google的A2A（Agent-to-Agent）协议就是为这个趋势准备的。当单个Agent能力有限时，让多个Agent协作。财务分析Agent和代码生成Agent各司其职，客服Agent处理不了的问题转给专业Agent——就像人类团队一样分工合作。 + +--- + +## 三、开发者核心竞争力：Harness Engineering + +### 为什么不是“调参侠” + +2026年做AI Agent开发，很多人会问：该学什么框架？该用哪个模型？ + +但真正的问题是：这个方向已经卷得不行了。模型会越来越聪明，但它们会继续以**意想不到的方式**失败。因为模型越强大，我们给它的任务就越复杂、越边界。 + +有个团队观察了一年代理开发失败案例，结论是：这不是模型问题，是**配置问题**（Configuration Problem）。 + +> coding agent = AI model(s) + harness + +你的编码Agent = AI模型 + 外部配置。这两样同样重要，甚至在某些场景下，harness（外围配置）决定了成败。 + +这就是**Harness Engineering**的核心理念：与其期待更强大的模型来解决所有问题，不如专注于如何最大化利用**当前**模型的能力。 + +### Harness Engineering是什么 + +Harness Engineering描述的是一种实践：通过调整Agent的配置点来定制和改进其输出质量和可靠性。 + +哪些属于配置点？ + +- **Skills**：静态上下文文件，包含文档、模式、示例 +- **MCP服务器**：运行时连接外部工具和数据源 +- **Sub-agents**：子代理分担复杂任务 +- **Memory**：长期记忆机制 +- **AGENTS.md文件**：项目级指令 + + +每个点都值得深挖。拿Skills来说，很多人不理解为什么有时候Agent不触发你的Skill——问题几乎永远不是Skill的内容，而是Skill的触发条件没设置好。 + +Skill的设计有几个关键原则： + +1. **清晰的触发条件**：什么情况下应该调用这个Skill？条件描述要精确。 +2. **足够的上下文**：不是塞越多越好，是塞得越精准越好。 +3. **可执行性**：给出具体步骤，不是抽象描述。 + +image-20260406220949474 + + +### 2026年开发者必备技能 + +基于对当前生态的分析，2026年AI Agent开发者需要具备的核心能力： + +**协议理解能力**：A2A、MCP、Skills这三个协议构成了2026年AI应用的基础设施。你不需要全部掌握，但需要理解它们各自的适用场景。 + +**系统设计能力**：Agent不是单兵作战。你需要设计多Agent协作的架构，考虑如何拆分任务、如何共享状态、如何处理异常。 + +**Prompt Engineering**：这个词已经被说烂了，但核心能力没变——如何清晰地表达意图，如何给出有效的约束。 + +**评估与调试**：Agent的执行过程往往是黑盒的。你需要建立有效的评估体系，知道什么时候Agent出了问题，问题出在哪里。 + +**成本意识**：Token是真实成本。你需要知道如何平衡效果和开销，如何设计高效的Agent系统。 + +--- + +## 四、技术生态：A2A、MCP与Skills的协作范式 + +### 三个核心概念的区别与联系 + +2026年的AI生态，有四个关键词你需要理解：**Agent**、**A2A**、**MCP**、**Skills**。 + +把它们放在一起看： + +- **Agent**是执行者——能自主决策的数字员工 +- **A2A**是Agent之间的协作协议——让多个Agent能沟通配合 +- **MCP**是Agent与外部世界的连接标准——让Agent能调用各种工具和数据 +- **Skills**是Agent的专业能力包——让Agent掌握特定领域的知识和操作 + +image-20260406221031543 + + +MCP和Skills是两种不同的扩展AI能力的方式，选择哪个取决于场景： + +MCP适合需要**实时数据**和**外部系统集成**的场景，比如查询数据库、调用内部API。 + +Skills适合需要**特定领域知识**和**操作规范**的场景，比如公司的代码规范、审批流程。 + +在实际项目中，你很可能同时用到两者。 + +### A2A协议的工作方式 + +Google主导的A2A协议，让Agent之间的协作变得标准化。 + +核心机制包括： + +**Agent Card**：每个Agent发布自己的“数字名片”，声明自己的能力和端点。 + +```json +{ + "name": "finance_analyzer", + "capabilities": ["data_analysis", "report_generation"], + "endpoint": "https://agent.example.com/a2a", + "version": "1.0" +} +``` + +**任务委托流程**： + +1. 服务发现——查找能完成任务的Agent +2. 任务协商——确认对方是否接受 +3. 执行监控——支持流式返回进度 +4. 结果返回——异步或同步获取结果 + + +这意味着你可以构建这样的多Agent系统：用户说“帮我开发一个电商网站”，规划Agent拆解任务后，委托给前端Agent、后端Agent、数据库Agent分别开发，最后由部署Agent负责上线。 + +### 框架演进：从功能堆砌到安全可控 + +主流框架（LangChain、CrewAI、AutoGen等）正在经历一次范式转变。 + +早期的框架追求功能丰富，什么都能做。现在的方向是**安全可控**： + +- **沙箱执行**：防止Agent执行危险操作 +- **权限控制**：Agent只能访问被授权的资源 +- **可观测性**：执行日志、性能监控、调试工具 +- **企业级部署**：容器化、高可用、资源管理 + +image-20260406182733856 + + + + +--- + +## 五、2026年六大趋势预判 + +### 趋势一：记忆机制的根本性改进 + +2026年AI Agent在长期自主性方面将实现关键突破。Context窗口处理能力将提升10倍以上，支持完整软件项目开发、跨部门业务流程等超大规模任务。 + +短期记忆增强、长期记忆架构、自进化能力——这三个层面的改进，将让Agent真正具备“持续工作”能力。 + +### 趋势二：语音AI加速崛起 + +人才增长最快的早期生成式AI公司集中在AI Agent应用，尤其是语音AI开发。企业正在为“人类通过对话而非文本界面与AI交互”的未来布局。 + +Meta接连收购语音AI初创企业，已经释放出行业整合的信号。 + +### 趋势三：AI并购潮 + +AI智能体解决方案在2025年Q1引领了年内的顶级AI退出交易。截至2025年，AI智能体与Copilot领域已发生35笔以上的收购。企业买家正日益寻求构建全面的智能体解决方案。 + +### 趋势四：利润压力蔓延 + +推理模型将输出的Token数量增加了约20倍。这意味着成本压力会从编程领域蔓延到其他垂直领域。初创公司需要重新思考商业模式。 + +### 趋势五：多Agent协作成为主流 + +单个Agent再强大，也无法覆盖所有场景。让多个Agent分工协作——财务Agent处理数据，代码Agent负责实现，客服Agent对接用户——将成为标准架构。 + +### 趋势六：AI原生工具崛起 + +从“传统产品+AI功能”转向“从头围绕AI功能构建”的工具和平台。这类产品不是为了替代传统软件，而是重新定义什么叫“智能工具”。 + +--- + +## 写在最后：2026 是 Agent 部署元年 + +回顾这篇文章的核心信息： + +- **现状**：AI Agent 已经从实验性概念进入生产部署阶段，72% 的企业至少在一个业务流程中部署了 Agent。 +- **类型**：Browser Agent、Coding Agent、Multi-Agent Team 三种类型各有优势，分别占据自动化、开发和复杂协作的场景。 +- **技术**：ReAct 范式、工具调用、记忆系统构成 Agent 的技术三角，让它真正具备感知-推理-行动-学习的闭环能力。 +- **生态**：A2A（Agent间协作协议）、MCP（模型-工具连接标准）、Skills（专业能力包）三者分工明确——A2A 让多个 Agent 能沟通配合，MCP 让 Agent 能调用外部工具，Skills 让 Agent 掌握特定领域知识。这三者构成了 2026 年 AI 应用的基础设施。 +- **开发者能力**：Harness Engineering 正在成为核心竞争力——与其期待更强的模型解决所有问题，不如专注于最大化利用当前模型的能力。Skills 触发条件、MCP 服务器配置、Sub-agents 分工、记忆机制调优，这些配置点决定了 Agent 的最终表现。 +- **落地路径**：企业导入应该从为员工配 Agent 切入，然后逐步走向流程 Agent 化和多 Agent 协作。 +- **安全底线**：安全治理不能缺席，沙箱、权限、人工复核、审计日志是标配。 + +image-20260406182931065 + +2025 年是 AI Agent 商业元年，那 2026 年就是 **Agent 部署元年**——从试点走向规模化的关键一年。 + +在这个转折点上，真正拉开差距的，不是谁用了最强的模型，而是： + +- 谁先在自己的真实业务中**跑通第一个 Agent 闭环**； +- 谁能在踩坑中迭代出**可复用的 Harness**； +- 谁能把 **A2A、MCP、Skills** 灵活组合，构建出真正稳定的多 Agent 系统。 + +技术不会等你准备好。 +但好消息是：**你不需要等到完美才能开始**。 + +--- + +## 参考来源 + +1. [15篇AI Agent研报，看懂2026年Agentic Al行业全景，附下载 - 知乎专栏](https://zhuanlan.zhihu.com/p/1996902325206405568) - Search Engine +2. [AI agent trends 2026 report | Google Cloud](https://cloud.google.com/resources/content/ai-agent-trends-2026?hl=zh-CN) - Search Engine +3. [深度解析Google《AI Agent Trends 2026》報告：那些成功的AI專案 ...](https://www.youtube.com/watch?v=1YokktIVqbc) - Search Engine +4. [2026：Agent 之年— AI 智能体如何重塑生产力与行业生态 - 知乎专栏](https://zhuanlan.zhihu.com/p/2005591914448193177) - Search Engine +5. [2026年做Agents 应该看这篇全面的技术综述 - 腾讯云](https://cloud.tencent.com/developer/article/2637134) - Search Engine +6. [2026年AI Agent厂商全景指南：从技术选型到价值落地 - 网易](https://www.163.com/dy/article/KPC8NOK30552NTBE.html) - Search Engine +7. [大模型退潮，AI Agent崛起！2026年AI四大变革，小白程序员必看](https://xingyun3d.csdn.net/69897b5754b52172bc5abece.html) - Search Engine +8. [2026年AI Agent六大趋势揭秘：编程热潮后下一个风口在哪？ - 36氪](https://eu.36kr.com/zh/p/3518938465770373) - Search Engine +9. [2026年Agentic AI十大关键趋势：技术、应用与治理三位一体](https://news.qq.com/rain/a/20260105A02WC200) - Search Engine +10. [2026 AI Agent生态全景解析：从单兵作战到智能协作的技术演进 ...](https://www.cnblogs.com/databank/p/19508724) - Search Engine +11. [Harness design for long-running application development - Anthropic](https://www.anthropic.com/engineering/harness-design-long-running-apps) - Search Engine +12. [How to Build an AI Agent from Scratch in 2026: A Complete Step-by ...](https://thecraftman.medium.com/how-to-build-an-ai-agent-from-scratch-in-2026-a-complete-step-by-step-guide-92247ef2ba65) - Search Engine +13. [Harness Engineering: The Skill That Will Define 2026 for Solo Devs](https://www.youtube.com/watch?v=DN2mhf0b02s) - Search Engine +14. [Skills Required for Building AI Agents in 2026 - DEV Community](https://dev.to/imaginex/skills-required-for-building-ai-agents-in-2026-2ed) - Search Engine +15. [MCP vs Skills: Understanding AI Coding Assistant Integrations in 2026](https://www.cosmicjs.com/blog/mcp-vs-skills-ai-coding-assistant-integrations-guide) - Search Engine +16. [Skill Issue: Harness Engineering for Coding Agents - HumanLayer](https://www.humanlayer.dev/blog/skill-issue-harness-engineering-for-coding-agents) - Search Engine +17. [Shipping Features to Close the AI Velocity Paradox - Harness](https://www.harness.io/blog/shipped-in-march-2026) - Search Engine diff --git "a/ai-articles/01-agent-and-coding/Agent Workflow Kit \346\216\245\345\205\245\344\275\240\347\232\204\351\241\271\347\233\256.md" "b/ai-articles/01-agent-and-coding/Agent Workflow Kit \346\216\245\345\205\245\344\275\240\347\232\204\351\241\271\347\233\256.md" new file mode 100644 index 0000000..fd9a3f7 --- /dev/null +++ "b/ai-articles/01-agent-and-coding/Agent Workflow Kit \346\216\245\345\205\245\344\275\240\347\232\204\351\241\271\347\233\256.md" @@ -0,0 +1,129 @@ +# Agent Workflow Kit 接入你的项目 + +> 日期：2026-05-21 + +最近使用 Codex 接手项目的时长大大增加了。 + +我自己做了很多项目，但做着做着往往就成了玩具，然后告别历史舞台。 + +但是我觉得这个过程是必要的，除非天选之子，否则大部分人有所成就的过程都是踩着 garbage 上去的。 + +但是这个过程，其实有可以缩短路径的空间。 + +我最近就在研究如何让 AI 把项目写的更完善，更像那么回事。 + +不同的项目是否适用不同的规约，changelog 如何写，artifact 如何做等。 + +不同的项目对工作流的运用如何，单人项目，短期项目是否适合融入 Agent workflow 。 + +不同的项目该用哪种 workflow，如何保证 agent.md 不会串线，遵照你的主规约？ + +如果项目里同时出现 OpenSpec、Superpowers、gstack 这些东西，到底谁说了算？ + +这些都是需要考虑的问题。 + +![image-20260521093654698](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260521093654698.png) + +之前爽用 AI 的时候，发现真夯啊，AI 一天，人间一年。 + +后来发现，这是我作为碳基生命出现的幻觉。 + +所以你看，不仅硅基生命有幻觉，碳基生命的幻觉更是多之又多。 + +有点跑偏题了。 + +--- + +最近一直在研究的一个路线是：Superpowers + OpenSpec + gstack ，是否是一个完备的工作流模式。 + +这个组合看似很丝滑（项目风格规约+文档先行+不同 agent 模式的 skill 技能），但是它的基础上是属于项目偏好型的，并不适合所有项目。 + +于是我就有了一个想法，做一个 AI 能看懂的文档，拿到一个项目来判断其是否适合接入 Agent workflow。 + +直接拿去喂 AI ，它会直接根据项目偏好来判断用哪种不同的 kit 。 + +想法不能光想。我把它做出来了，叫 Agent Workflow Kit。 + +https://github.com/crisxuan/agent-workflow-kit + +![image-20260521093529414](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260521093529414.png) + +它不是又一个工具，它是一份给 AI 看的文档，外加一套打包好的 skill。 + +它不替你做决定，它帮你判断。 + +核心就一句话：先评估，再接入。 + +不是所有项目都配得上一套重流程。一个一次性脚本，你非要给它上 OpenSpec，那不叫规范，那叫行为艺术。 + +![image-20260521093611504](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260521093611504.png) + +所以它干的第一件事，是让 AI 给你的项目打分。 + +它会从八个维度打分：生命周期、用户、UI、发布风险、安全、外部平台、测试难度、协作，每项 0 到 2 分，满分 16。 + +image-20260521093841112 + +然后按分数告诉你：这项目该用 Level 几的 workflow，要不要规格层，要不要执行纪律，要不要专家审查。 + +下面是一个完整的中型 Web App 项目的工作流程。 + +![](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260521094606666.png) + +![](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260521094630324.png) + +说白了，它不让你为了“显得专业”去堆流程。 + +（当然确实大多数项目头重脚轻，轻轻说的） + +--- + +那它怎么接入你自己的项目？ + +最糙的办法：把仓库里那份中文文档整个喂给 AI，问它“我这项目该用哪种 workflow”。 + +讲究一点，用它打包好的 skill，一句话就够： + +```text +使用 $agent-workflow-kit-zh-cn 评估这个仓库，并推荐合适的 AI 工作流级别。 +``` + +AI 会先把你的仓库翻一遍，再吐回来一份 Decision：项目类型、风险分、建议级别、该建哪些文件、验证命令是什么，理由是什么。 + +你看完点头，它才动手写 AGENTS.md。 + +你不点头，它就只是个秘书。 + +有一句话挺好的，有事儿秘书干。。。。。。 + +它也不会自作主张帮你装工具、开 hook、push 代码，这些都得你先点头。 + +毕竟它再聪明，出了事背锅的还是你。 + +还有一点，我自己挺在意的。 + +它不绑定任何工具。 + +Superpowers、OpenSpec、gstack 这些，在文档里全都只是“示例”，不是“你必须装”。 + +image-20260521094038035 + +我不想做一个你得按我的来的东西。 + +我想做的是一个你先想清楚自己到底需要什么的东西。 + +或者说你的 Agent 知道你想要什么的东西。 + +--- + +最后，说回开头。 + +它不会让你的玩具项目起死回生。该成玩具的，还是会成玩具。 + +但它至少能让 AI 在帮你堆 garbage 的时候，堆得有那么点章法。 + +让你下次踩着往上走的那堆，台阶高一点。 + +这就够了。 + +欢迎大家提出 issue、PR。 diff --git "a/ai-articles/01-agent-and-coding/Agents.md \346\230\257\344\273\200\344\271\210.md" "b/ai-articles/01-agent-and-coding/Agents.md \346\230\257\344\273\200\344\271\210.md" new file mode 100644 index 0000000..a43d6ef --- /dev/null +++ "b/ai-articles/01-agent-and-coding/Agents.md \346\230\257\344\273\200\344\271\210.md" @@ -0,0 +1,585 @@ +# Agents.md 是什么 + +> 日期：2026-06-09 + + +在真实项目里，Codex 不只需要会写代码，还需要知道这个项目的规矩：用什么命令、跑什么测试、哪些文件不能动、哪些操作要先确认。 + +这些内容如果每次都手动敲，很麻烦，也容易漏。 + +`AGENTS.md` 的作用就是把这些规则写下来，让 Codex 每次进入项目时自动读取。 + +它解决的是“让 Codex 更懂这个项目”的问题。 + +我一直用了很久的 Codex，一直还没有认真了解过 `AGENTS.md` 是什么。 + +这篇文章就来详细拆解一下。 + +--- + +简单来说，`AGENTS.md` 就是给 Agent 看的 README。 + +`README.md` 是给人看的，让你快速知道这个仓库是干嘛的。 + +`AGENTS.md` 是给 Codex 看的，让 Codex 在改代码前知道这个仓库有哪些工程约定。 + +比如： + +- 这个项目怎么启动 +- 修改代码后要跑什么测试 +- 哪些目录不能动 +- 用什么包管理器 +- 新增依赖要不要先确认 +- 数据库、API、前端分别有什么约定 + +注意，文件名建议写成： + +```shell +AGENTS.md +``` + +不要写成 `Agent.md`、`Agents.md` 或者 `agents.md`。 + +大小写不一致，有些场景下可能会导致加载不到。 + +## 全局 AGENTS.md + +全局 `AGENTS.md` 一般放在： + +```shell +~/.codex/AGENTS.md +``` + +如果没有这个目录，可以先创建： + +```shell +mkdir -p ~/.codex +``` + +全局 `AGENTS.md` 适合放你长期的个人偏好。 + +比如： + +```md +# ~/.codex/AGENTS.md + +## Working agreements + +- 默认用中文回复。 +- 修改代码前先阅读相关文件。 +- 优先使用项目现有风格。 +- 不要擅自覆盖用户已有改动。 +- 新增生产依赖前先确认。 +- 如果无法运行验证命令，说明原因。 +``` + +这些规则不依赖某个仓库，换任何项目都成立。 + +所以它适合放全局。 + +写完之后，可以用下面这个命令验证： + +```shell +codex --ask-for-approval never "Summarize the current instructions." +``` + +我这里跑了一下： + +image-20260609103020648 + +如果输出里出现了你写进去的规则，就说明全局 `AGENTS.md` 生效了。 + +输出里如果还有一些英文规则，也正常。 + +因为这个命令总结的是“当前所有生效指令”，不只包含你的 `AGENTS.md`，还包含 Codex 自带的系统规则、当前工作目录、审批策略、沙箱权限等信息。 + +## 全局和项目级怎么分 + +`AGENTS.md` 可以放在不同位置。 + +最常见的是这三个层级： + +```shell +~/.codex/AGENTS.md # 全局规则 +repo/AGENTS.md # 项目规则 +repo/apps/web/AGENTS.md # 子模块规则 +``` + +它们不是互斥关系。 + +不是说有了全局 `AGENTS.md`，项目 `AGENTS.md` 就不生效了。 + +它们会一起加载。 + +可以简单理解成： + +- 全局规则：我希望 Codex 一直怎么工作 +- 项目规则：这个仓库具体怎么工作 +- 子目录规则：这个模块有什么特殊要求 + +判断标准也很简单： + +- 换一个项目仍然成立：放全局 +- 只在这个仓库成立：放项目 +- 只在某个子目录成立：放子目录 + +比如“新增生产依赖前先确认”，适合放全局。 + +比如“修改 Prisma schema 后运行 `pnpm db:generate`”，适合放项目。 + +因为不是每个项目都用 Prisma。 + +这里解释一下。 + +`Prisma` 是 Node.js/TypeScript 生态里常见的数据库工具。你可以简单理解成：它把数据库表结构、类型和查询代码连接起来，让你在代码里用类型安全的方式操作数据库。 + +很多使用 Prisma 的项目里会有： + +```shell +prisma/schema.prisma +``` + +这个文件描述数据库里有哪些表、字段和关系。 + +当你修改了这个 schema 后，项目通常需要重新生成数据库客户端代码。 + +`pnpm db:generate` 一般就是项目里封装好的脚本，背后可能执行的是： + +```shell +prisma generate +``` + +所以这条规则的意思是： + +```text +如果你改了数据库结构定义，不要只改文件就结束，还要重新生成数据库客户端。 +``` + +但不是每个项目都用 Prisma，也不是每个项目都有 `db:generate` 这个脚本。 + +所以它是典型的项目级规则，不适合放到全局 `~/.codex/AGENTS.md`。 + +## 项目级 AGENTS.md + +项目级 `AGENTS.md` 一般放在仓库根目录： + +```shell +repo/AGENTS.md +``` + +它应该写这个项目的具体工程约定。 + +比如： + +- 安装命令 +- 启动命令 +- 测试命令 +- 类型检查命令 +- lint 命令 +- 目录结构 +- 生成文件边界 +- 数据库变更要求 +- API 文档同步要求 + +如果是生产项目，可以直接使用文末那份模板，再按项目实际情况删改命令和目录。 + +## 验证项目级 AGENTS.md + +我按照上面的 Project Scope 的 `AGENTS.md` 创建了一个测试项目。 + +目录大概是这样： + +```shell +agents-md-test/ + AGENTS.md + apps/ + web/ + packages/ + ui/ + db/ + services/ + payments/ + docs/ + api/ + src/ + generated/ +``` + +在项目根目录执行： + +```shell +codex --ask-for-approval never "List the instruction sources you loaded and summarize the Project commands, Project structure, and Rules sections." +``` + +也可以测试某个子目录： + +```shell +codex --cd services/payments --ask-for-approval never "List the instruction sources you loaded." +``` + +输出测试： + +image-20260609132036337 + +一句话： + +验证 `AGENTS.md` 是否生效，不要只看它有没有说“加载了 AGENTS.md”。 + +最好让它把里面的独有规则总结出来。 + +比如输出里出现了： + +```text +pnpm dev +src/generated +pnpm db:generate +docs/api +``` + +这些都是项目级 `AGENTS.md` 里的独有内容。 + +能看到这些，就说明项目级规则确实生效了。 + +## 子目录 AGENTS.md + +除了项目根目录之外，子模块也可以用 `AGENTS.md` 来做更细的约束。 + +比如： + +```shell +repo/ + AGENTS.md + services/ + payments/ + AGENTS.md + search/ + AGENTS.md +``` + +`repo/AGENTS.md` 写整个仓库通用的规则。 + +`services/payments/AGENTS.md` 写支付服务自己的规则。 + +`services/search/AGENTS.md` 写搜索服务自己的规则。 + +比如支付服务里可能会写： + +```md +# services/payments/AGENTS.md + +## Payments Rules + +- Do not change billing behavior without updating payment tests. +- Do not log card numbers, tokens, or customer secrets. +- Run `pnpm test payments` after changing payment logic. +``` + +这对 monorepo 很有用。 + +因为一个仓库里可能同时有前端、后端、支付、搜索、数据任务，每个模块的风险点都不一样。 + +## AGENTS.override.md 是什么 + +除了 `AGENTS.md`，还有一个文件名叫： + +```shell +AGENTS.override.md +``` + +它的优先级比同目录下的 `AGENTS.md` 更高。 + +比如： + +```shell +repo/ + AGENTS.md # 仓库根规则 + services/ + payments/ + AGENTS.md # 会被忽略 + AGENTS.override.md # 实际生效 + README.md + search/ + AGENTS.md +``` + +在 `services/payments/` 目录下，同时存在： + +```shell +AGENTS.md +AGENTS.override.md +``` + +这时 Codex 会优先使用： + +```shell +services/payments/AGENTS.override.md +``` + +而忽略同目录下的： + +```shell +services/payments/AGENTS.md +``` + +`AGENTS.override.md` 适合用在需要强覆盖的场景。 + +比如： + +- 某个子服务有特殊安全规则 +- 某个目录禁止修改生成文件 +- 某个模块必须用特殊测试命令 +- 想临时替换原来的 `AGENTS.md` 行为 + +普通情况下，用 `AGENTS.md` 就够了。 + +只有明确想覆盖同目录 `AGENTS.md` 时，才用 `AGENTS.override.md`。 + +## 自定义 fallback 文件名 + +有些团队可能已经有自己的项目说明文件了。 + +比如： + +```shell +TEAM_GUIDE.md +.agents.md +``` + +如果不想把这些文件改名成 `AGENTS.md`，可以在 Codex 配置里设置 fallback 文件名。 + +编辑： + +```shell +~/.codex/config.toml +``` + +加入： + +```toml +project_doc_fallback_filenames = ["TEAM_GUIDE.md", ".agents.md"] +project_doc_max_bytes = 65536 +``` + +然后重启 Codex，或者重新运行一条新的 `codex` 命令。 + +配置后，Codex 在每个目录里会按这个顺序查找： + +```text +AGENTS.override.md +AGENTS.md +TEAM_GUIDE.md +.agents.md +``` + +不在这个列表里的文件名会被忽略。 + +比如 `README.md` 不会因为它存在，就自动变成 Codex 的 instructions 文件。 + +`project_doc_max_bytes` 控制的是项目说明文件合并后的最大字节数。 + +如果规则很多，可以适当调大。 + +## 使用 CODEX_HOME 切换配置目录 + +默认情况下，Codex 使用： + +```shell +~/.codex +``` + +作为自己的主目录。 + +所以全局 `AGENTS.md` 默认是： + +```shell +~/.codex/AGENTS.md +``` + +如果你想临时使用另一套配置，可以设置 `CODEX_HOME`： + +```shell +CODEX_HOME=$(pwd)/.codex codex exec "List active instruction sources" +``` + +这条命令的意思是： + +本次执行不要使用默认的 `~/.codex`，而是使用当前项目下的： + +```shell +$(pwd)/.codex +``` + +适合这些场景： + +- 给项目自动化任务准备单独配置 +- 区分个人配置和 CI 配置 +- 临时测试不同的 `AGENTS.md` +- 避免污染默认 `~/.codex` + +如果规则看起来不对，可以先检查： + +```shell +echo $CODEX_HOME +``` + +如果它不是空的，说明 Codex 当前使用的不是默认 `~/.codex`。 + +## 可以直接抄的生产级 AGENTS.md + +最后放一份我觉得更适合生产项目的 `AGENTS.md`。 + +这份模板偏工程纪律型，适合多人协作项目、monorepo、涉及数据库、API、CI 的项目。 + +你可以直接复制到项目根目录，再按项目实际情况删改。 + +```md +# AGENTS.md + +Working agreement for AI coding agents in this repository. + +On conflict, follow: explicit user instructions > this file > existing code conventions > your defaults. + +When the choice is risky or materially affects architecture, data, security, or public behavior, stop and ask rather than guess. + +## Orientation + +Do this first, every session. + +Before writing any code, build a working model of the repo from what is actually there: + +- Read `README`, `CONTRIBUTING`, and any root-level `*.md` files for setup and norms. +- Detect the package manager from the lockfile: + - `pnpm-lock.yaml` -> `pnpm` + - `yarn.lock` -> `yarn` + - `package-lock.json` -> `npm` + - `uv.lock` or `poetry.lock` -> the matching Python tool +- Use the detected package manager. Never introduce a second package manager. +- Find the real commands in `package.json` scripts, `Makefile`, `Taskfile`, `justfile`, or CI config. +- Treat CI config (`.github/workflows`, `.gitlab-ci.yml`, etc.) as the source of truth for what passing means. +- Read the files you are about to change and their tests before editing. +- Do not assume a stack. Verify it from the repo. + +## Core Principles + +- Make the smallest change that solves the task. +- Do not do drive-by refactors, renames, or reformatting of untouched code. +- Keep unrelated changes out of the diff. +- Match the surrounding code: naming, structure, error handling, and test style. +- Consistency beats personal preference. +- Reuse existing helpers, components, and patterns before adding new ones. +- Do not add speculative abstractions, config, or error handling for cases that do not exist yet. +- Comments should explain non-obvious decisions. Do not comment what the code already says. + +## Verification + +Required before calling a task done: + +- Use the project's defined commands. Prefer focused checks first, then broader checks. +- Run the narrow tests for the file, package, or feature you touched. +- Then run the broader gate that the project defines: lint, typecheck or compile, and tests. +- Mirror CI locally when practical. +- Do not invent unrelated verification commands just to have something to run. +- Fix failures caused by your change. +- Add or update tests for behavior changes. +- If you cannot run a command because of missing services, credentials, network, or time, say so explicitly. +- Never imply tests passed if you did not run them. + +## Dependencies + +- Do not add a production dependency without asking first. +- When requesting a dependency, explain why the existing tools are not enough. +- Dev-only tooling is lower risk, but still match what the repo already uses. +- Never edit generated files, vendored code, or lockfiles by hand. +- Regenerate generated files and lockfiles through the project's documented command. + +## Git And PR + +- Commit only when asked. +- If asked to commit and currently on the default branch, create a feature branch or ask before committing. +- Add files by name. Do not use `git add .` or `git add -A`. +- Use conventional commit subjects when committing, such as `feat:`, `fix:`, or `chore:`. +- Keep one logical change per commit. +- Never run `push --force`, `reset --hard`, `branch -D`, `clean -f`, or `--no-verify`. +- Do not amend, squash, or rebase already-pushed commits unless asked. +- Do not revert or overwrite changes you did not make. + +## Security + +- Never commit secrets, tokens, keys, or credentials. +- Treat `.env*` files as sensitive. +- Do not print secret values or write them to logs. +- Validate external input at trust boundaries. +- When changing access to user-visible data, check the authorization path. +- Do not log PII or customer data. + +## Data And Migrations + +- Treat schema changes and migrations as high risk. +- Do not create or modify production migrations unless the task explicitly asks for it. +- Flag destructive changes in your summary, including dropped columns, deleted rows, and irreversible backfills. +- Wait for confirmation before applying destructive data changes. + +## When To Stop And Ask + +Pause and ask before: + +- Adding a production dependency or new framework. +- Adding a broad new abstraction. +- Touching production data, schema, or migrations. +- Making a breaking change to a public API or shared interface. +- Editing shared config, CI, or the build pipeline. +- Continuing when the task contradicts the code. +- Choosing between several valid approaches when there is no clear winner. + +## Reporting Back + +End each task with: + +- What changed, by file. +- How it was verified, including commands run and results. +- What was not run, and why. +- Risks or follow-ups. +``` + +这份模板不绑定具体技术栈，所以比前面那种写死 `pnpm`、`Prisma`、`docs/api` 的模板更通用。 + +它的重点是让 Codex 先读项目、再判断命令、再做最小修改，最后把验证和风险讲清楚。 + +如果你的项目已经有明确技术栈，也可以继续往里面加项目规则。 + +比如： + +```md +- After changing Prisma schema, run `pnpm db:generate`. +- API changes must update files under `docs/api`. +- Frontend changes must pass `pnpm test apps/web`. +``` + +也就是说，这份模板适合作为项目级 `AGENTS.md` 的底座，再叠加你项目自己的命令和边界。 + +## 总结 + +`AGENTS.md` 本质上就是给 Codex 看的项目说明书。 + +全局 `~/.codex/AGENTS.md` 放长期偏好。 + +项目 `repo/AGENTS.md` 放工程规则。 + +子目录 `AGENTS.md` 放模块规则。 + +`AGENTS.override.md` 用来覆盖同目录普通规则。 + +如果团队已经有自己的说明文件，也可以通过 `project_doc_fallback_filenames` 加入 fallback list。 + +最重要的是，`AGENTS.md` 不要写空话。 + +不要写： + +```text +请保持代码优雅。 +请遵循最佳实践。 +``` + +要写能影响 Codex 行为、也能被命令验证的规则。 + +这种才是真正有用的工程化约束。 diff --git "a/ai-articles/01-agent-and-coding/Anthropic \350\277\231\346\255\245\346\243\213\350\265\260\345\276\227\346\274\202\344\272\256\357\274\232Claude \347\232\204\343\200\214\347\255\226\347\225\245\351\241\276\351\227\256\343\200\215\346\250\241\345\274\217\357\274\214\346\255\243\345\234\250\351\207\215\346\226\260\345\256\232\344\271\211 AI Agent \347\232\204\346\210\220\346\234\254\346\226\271\347\250\213\345\274\217.md" "b/ai-articles/01-agent-and-coding/Anthropic \350\277\231\346\255\245\346\243\213\350\265\260\345\276\227\346\274\202\344\272\256\357\274\232Claude \347\232\204\343\200\214\347\255\226\347\225\245\351\241\276\351\227\256\343\200\215\346\250\241\345\274\217\357\274\214\346\255\243\345\234\250\351\207\215\346\226\260\345\256\232\344\271\211 AI Agent \347\232\204\346\210\220\346\234\254\346\226\271\347\250\213\345\274\217.md" new file mode 100644 index 0000000..a46951c --- /dev/null +++ "b/ai-articles/01-agent-and-coding/Anthropic \350\277\231\346\255\245\346\243\213\350\265\260\345\276\227\346\274\202\344\272\256\357\274\232Claude \347\232\204\343\200\214\347\255\226\347\225\245\351\241\276\351\227\256\343\200\215\346\250\241\345\274\217\357\274\214\346\255\243\345\234\250\351\207\215\346\226\260\345\256\232\344\271\211 AI Agent \347\232\204\346\210\220\346\234\254\346\226\271\347\250\213\345\274\217.md" @@ -0,0 +1,93 @@ +# Anthropic 这步棋走得漂亮 + +> 日期：2026-04-16 + +看到一篇推文说是 Anthropic 又新发布了一种新的形式，叫做 `advisor strategy` ，翻译为战略顾问。它的主要形式不难理解，我给大家解读下： + +![image-20260416052313353](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260416052313353.png) + +首先 Advisor 是一个「决策者」的角色，这个角色也是一个战略顾问，全能型人才，负责把控一切，但是它不主要做事儿，这个角色由 Opus 4.6 来承载。 + +Executor 是一个「执行者」角色，这个角色的定位是工匠~~说白了就一臭打工的~~，负责执行，干活，运行，自循环。Executor 可以做很多任务，用很多 ide、db、中间件、框架、前端，想咋用咋用，把活干了就行。 + +看到这里你也许会发现，这 TM 不就是像极了我现在天选打工人的角色吗？只不过这次的对象换成了 Claude Code，这不是天选打工人了，这是**天选 Agent**。最终还是 Sonnet 和 Haiku 背锅扛下了所有。 + +好了看到这里，如果你理解了下文就不用看了，如果你觉得有点意思，不妨看下去，多陪我一会儿。 + +--- + +这不是一个小功能更新。在我看来，这是 Anthropic 对当前 AI Agent 领域最深刻矛盾的一次正面回应。 + +## 一个真实的行业痛点 + +过去一年，AI Agent 的叙事非常热闹。大家都在讲「让 AI 自主完成复杂任务」，但真正把 Agent 跑在生产环境里的团队都知道，**成本**真的烧不起。 + +逻辑很简单。你希望 Agent 足够聪明，能在复杂场景下做出正确判断——那你就得用最强的模型。但最强的模型意味着最贵的推理成本。而 Agent 的特点偏偏是调用频繁、上下文长、工具交互多，每一轮都在烧钱。 + +很多团队的做法是「忍痛用大模型」或者「硬着头皮用小模型然后接受更高的失败率」。这两条路都不太走得通。 + +## Anthropic 的解法：让小模型开车，大模型坐副驾 + +Advisor Strategy 的核心思路，说起来其实非常直觉： + +**Sonnet（或 Haiku）负责完整的任务执行**——调用工具、读写文件、和用户交互、循环迭代，所有脏活累活它来干。当它遇到超出自身能力的决策点时，它会主动「举手」，把问题交给 Opus。 + +**Opus 作为顾问介入**——它不直接操作任何工具，不生成面向用户的输出，它只做一件事：给出方向性判断。然后 Sonnet 拿着这个判断继续执行。 + +技术实现上，Anthropic 把它做成了 Messages API 里的一个内置工具类型 `advisor_20260301`。开发者只需要在请求里加一个工具声明，就能激活这个模式。所有的模型间通信都发生在一次 API 请求内部，不需要额外的网络往返。 + +这里面有一个关键设计：`max_uses` 参数。你可以精确控制每次请求中 Opus 最多被咨询几次。这不是一个「要么全用大模型，要么全用小模型」的二选一，而是一个**连续的、可调节的智能-成本光谱**。 + +## 数据说话 + +Anthropic 给出的基准测试数据相当有说服力： + +**Sonnet + Opus 顾问**的表现是——在 SWE-bench Multilingual 上相比 Sonnet 单独运行提升了 2.7 个百分点，同时每个 Agent 任务的成本反而降低了 11.9%。性能更好，成本更低，这在大模型领域是非常少见的「帕累托改进」。 + +image-20260410083610654 + +更有意思的是 **Haiku + Opus 顾问**的数据。Haiku 单独在 BrowseComp 上只能拿到 19.7% 的分数，加上 Opus 顾问之后直接翻倍到 41.2%——虽然还追不上 Sonnet 单独跑的成绩，但成本只有 Sonnet 的 15%。对于那些高并发、对成本敏感但又不能容忍太低智能水平的场景，这个组合打开了一个全新的可用区间。 + +![image-20260410083727340](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260410083727340.png) + +## 为什么说这步棋走得漂亮 + +这个策略的精妙之处不仅仅在于技术实现，更在于它背后的产品哲学。 + +**第一，它重新定义了「模型能力」的边界。** + +以前我们评价一个模型，基本就是看它的绝对能力上限。Opus 最强，所以要做难事就得用 Opus。但 Advisor Strategy 告诉你：一个模型的有效能力不只取决于它自身的参数量，还取决于它能调用什么级别的「大脑」。Sonnet 加上 Opus 顾问，在很多任务上的表现已经逼近甚至超过了 Opus 直接执行——但成本天差地别。 + +这本质上是在说：**模型的能力可以被组合出来，而不是只能被训练出来。** + +**第二，它把 Agent 架构从「分治」推向了「升级」。** + +之前业界主流的多模型协作模式是 Orchestrator 模式——大模型做规划、分解任务，小模型去执行子任务。这个模式的问题在于，大模型承担了全部的规划成本，而且任务分解本身就是一种信息损耗。 + +Advisor 模式反过来了。小模型拥有完整的上下文和执行控制权，它只在真正需要的时候才去咨询大模型。这意味着大模型的推理能力被用在了刀刃上，而不是浪费在那些小模型完全可以自己搞定的常规操作上。 + +**第三，它给 Anthropic 自己建立了一个完美的商业飞轮。** + +想想看：这个功能让开发者有动力同时使用 Anthropic 的多个模型，而不是只选其中一个。 + +开发者在 Haiku 的低成本和 Opus 的高智能之间不再是非此即彼，而是可以灵活混搭。这意味着 Anthropic 的每个模型层级都有了清晰的商业价值——Haiku 靠量，Opus 靠质，Sonnet 居中调和。 + +对开发者来说，这降低了选择焦虑；对 Anthropic 来说，这最大化了模型矩阵的整体收入。双赢。 + +## 对行业的启示 + +Advisor Strategy 的推出，让我想到几件更大的事。 + +首先，**AI 基础设施的竞争正在从「谁的模型最大」转向「谁的调度最聪明」**。模型本身的能力当然重要，但如何把不同级别的模型编排在一起、让总体的性价比最优化，这正在成为新的竞争维度。 + +其次，**这可能会加速 AI Agent 的真正落地**。很多企业不是不想用 Agent，是算了一笔账之后觉得 ROI 不划算。如果一个简单的 API 参数调整就能让 Agent 的运行成本降低 85%，同时智能水平翻倍，那很多之前算不过来的账突然就算得过来了。 + +最后，这也给竞争对手们出了一道题。OpenAI、Google 接下来是跟进类似的分层策略，还是试图用更便宜的单一大模型来正面竞争？这个选择本身就很有看头。 + +## 写在最后 + +技术行业有一个常见的误区：把「用更大的模型」等同于「更好的解决方案」。Anthropic 的 Advisor Strategy 用一种优雅的方式证明了——**聪明地组合，往往比粗暴地堆料更有效**。 + +这让我想起软件工程领域一个古老的道理：好的架构不是让每个组件都变成最强的，而是让每个组件在最合适的位置发挥恰好的作用。 + +Opus 不需要全程在线，它只需要在关键时刻说对那几句话。这不正是「顾问」的精髓吗？ diff --git "a/ai-articles/01-agent-and-coding/Claude Code 100\344\270\207\344\270\212\344\270\213\346\226\207\357\274\232\345\210\260\345\272\225\346\230\257\347\234\237\351\234\200\346\261\202\350\277\230\346\230\257\350\220\245\351\224\200\345\272\237\350\257\235.md" "b/ai-articles/01-agent-and-coding/Claude Code 100\344\270\207\344\270\212\344\270\213\346\226\207\357\274\232\345\210\260\345\272\225\346\230\257\347\234\237\351\234\200\346\261\202\350\277\230\346\230\257\350\220\245\351\224\200\345\272\237\350\257\235.md" new file mode 100644 index 0000000..157b653 --- /dev/null +++ "b/ai-articles/01-agent-and-coding/Claude Code 100\344\270\207\344\270\212\344\270\213\346\226\207\357\274\232\345\210\260\345\272\225\346\230\257\347\234\237\351\234\200\346\261\202\350\277\230\346\230\257\350\220\245\351\224\200\345\272\237\350\257\235.md" @@ -0,0 +1,98 @@ +# Claude Code 100 万上下文：到底是真需求还是营销废话？ + +> 日期：2026-04-16 + +## 背景 + +Anthropic 官方博客发了一篇技术文章，讲 Claude Code 是怎么做会话管理的，以及 100 万 Token 上下文在实际开发里到底怎么用。 + +老实说，这个话题在开发者社区引起了不小的讨论。有人觉得这是工程上的突破，也有人在问：一般人真的用得上吗？ + +--- + +## 官方怎么说 + +Anthropic 那篇博客的核心内容是关于会话管理的架构设计。三个阶段： + +**会话初始化** → 读取项目文件、扫描目录、构建初始上下文 + +**对话循环** → 用户输入 → Claude 推理 → 工具调用 → 结果写回上下文，每个循环都会重新计算可用空间 + +**会话持久化** → 写入 `.claude` 目录，支持跨会话恢复 + +这套系统的本质是**上下文生命周期管理**，不是简单地把对话历史塞进去。它会动态决定什么内容该保留、什么该压缩、什么该丢弃。 + +--- + +## 网上争什么 + +Reddit 上有个帖子标题很直接：**「100 万上下文对 99% 的用户来说就是营销废话」**。 + +这个观点有它的道理。核心批评是： + +大多数人的日常开发场景，单个文件几百行、一个项目几十个文件，塞进 100 万上下文就像用油轮去送一份外卖——不是不能，是没必要。 + +HN 上的讨论更理性一些。有人提到，100 万上下文真正的价值场景是： + +- 一次性消化整个代码库（尤其是接手老项目） +- 大型重构任务，Claude 需要同时理解几十个文件的关系 +- 长线任务，比如让 AI 记住你项目里所有历史决策 + +但同时有人指出实际问题：上下文越长，每次 API 调用的延迟越高，成本也越高。用 100 万上下文跑一个简单任务，等于用牛刀杀鸡。 + +--- + +## 一个 trade-off 判断 + +不是所有人都在处理需要 100 万上下文的场景。但有些开发者确实是。 + +比如你接手一个三年前的老项目，代码没有文档、架构没人说得清。这时候 100 万上下文能让你一次性把整个代码库喂给 Claude，让它自己理解模块之间的关系。这比起逐个文件复制粘贴，效率是质的提升。 + +再比如你要做跨文件重构，改一个函数会影响二十个文件。传统方式是你告诉 Claude 每个文件改什么，Claude 可能忘掉；100 万上下文让 Claude 始终看到全局，改动的连贯性完全不一样。 + +**但**如果你日常就是改改小功能、写写脚本，100 万上下文对你来说确实感知不强。 + +这不是技术不行，是使用场景不匹配。 + +--- + +## 社区的另一个关注点：成本 + +有个 YouTube 视频的标题很实在：**「不要用 Claude 的 100 万上下文，除非你看过这个」** + +成本是真实的问题。上下文越长，每次请求的 Token 消耗越大。在公测期可能感知不强，但正式收费后，长期跑大上下文session的成本会成为选择门槛。 + +这也是为什么很多人更关心的是：**什么时候该用它，什么时候不该用它。** + +--- + +## 官方文档透露的细节 + +Claude Code 的模型配置文档里提到，100 万上下文是通过 Claude 3.5 Sonnet 实现的，支持在代码.claude.com 项目里直接开启。 + +实际操作上，用户可以在项目里配置是否启用 100 万上下文模式。启用后，Claude 会自动管理上下文窗口，包括对长输出做摘要、动态调整对话历史的占比、优先保留代码文件而非对话记录。 + +这意味着官方也承认了上下文空间是稀缺资源，需要精细管理。 + +--- + +## 一个判断 + +100 万上下文不是噱头，但也不是人人需要。 + +它的目标用户是：**需要 AI 同时理解大量信息的场景**。接手大型代码库、复杂重构、跨模块分析，这类任务它能显著降低沟通成本。 + +但如果你的日常工作是在单个文件里写函数、调 API，100 万上下文对你的意义更多是心理安慰而不是实际效率提升。 + +营销层面，Anthropic 宣传 100 万确实吸引眼球。真实价值上，它是有选择性地释放给有相应需求的开发者。 + +**不是所有人都需要一头大象，但你不能否认大象在需要的时候比蚂蚁管用。** + +--- + +Sources: +- [Using Claude Code Session Management and 1M Context](https://claude.com/blog/using-claude-code-session-management-and-1m-context) +- [1M context window is basically marketing BS for 99% of users - Reddit](https://www.reddit.com/r/ClaudeCode/comments/1qxaddx/1m_context_window_is_basically_marketing_bs_for/) +- [HN Discussion on Claude Code 1M Context](https://news.ycombinator.com/item?id=46902427) +- [Claude Code 1M Context Window: Cost, Limits, and When to Use](https://www.claudecodecamp.com/p/claude-code-1m-context-window) +- [Claude 1M Token Context Window: What It Means for AI Agents](https://www.mindstudio.ai/blog/claude-1m-token-context-window-ai-agents/) diff --git "a/ai-articles/01-agent-and-coding/Codex \344\270\200\347\233\264 Reconnecting\357\274\237\346\210\221\346\234\200\345\220\216\345\217\221\347\216\260\357\274\214\345\270\270\350\247\201\345\260\261\344\270\244\344\270\252\345\235\221.md" "b/ai-articles/01-agent-and-coding/Codex \344\270\200\347\233\264 Reconnecting\357\274\237\346\210\221\346\234\200\345\220\216\345\217\221\347\216\260\357\274\214\345\270\270\350\247\201\345\260\261\344\270\244\344\270\252\345\235\221.md" new file mode 100644 index 0000000..3675302 --- /dev/null +++ "b/ai-articles/01-agent-and-coding/Codex \344\270\200\347\233\264 Reconnecting\357\274\237\346\210\221\346\234\200\345\220\216\345\217\221\347\216\260\357\274\214\345\270\270\350\247\201\345\260\261\344\270\244\344\270\252\345\235\221.md" @@ -0,0 +1,90 @@ +# Codex 一直 Reconnecting？我最后发现，常见就两个坑 + +> 日期：2026-06-05 + + +我估计大家在用 Codex 的时`候，一定对这个场景并不陌生。 + +当你打算让 Codex 开始干活的时候，当你想让 Codex 给出有效指导的时候，当你想用 Codex 跑任务的时候。 + +image-20260602220945257 + +这个 Reconnecting 是神 TM 烦，这到底是啥玩意？ + +别急，这个 Reconnecting ，有说法的。 + +--- + +一般来说，这个 Reconnecting 的出现，会分为两种情况： + +1. Codex 没有走代理 +2. 已经连到服务器，但被服务器拒绝 + +先说第一种情况，这个大家应该都能理解，毕竟你都用上 Codex 了，肯定能理解咋回事了。 + +但是这种连不上，它在日志中直接体现的就是 **WebSocket 握手超时**。 + +为什么会这样？因为 Codex Desktop 是一个桌面应用，它不像浏览器那样会自动吃系统代理。它启动的时候，需要显式读取环境变量里的 `HTTP_PROXY`、`HTTPS_PROXY` 这些，才会走代理。如果这些变量没设，它就以为自己能直达，结果就是等半天没响应，只好进入重连循环。 + +这种情况的处理方式是直接在 `~/.codex/.env` 中写入代理变量。 + +以 Mac 为例，如果你用的是 Clash 或类似工具，常见 HTTP/SOCKS5 混合端口是 `7890`，但每个人的实际端口可能不一样，所以动手前最好先确认一下。你可以直接看代理工具的设置，或者在终端跑一下 `env | grep -i proxy` 看看当前 shell 已经用了什么 + +大家可以直接用我下面的 Prompt ，直接让 Codex 给你加上，如果你 Codex 实在连不上，用其他 Agent 也行。 + +```prompt +帮我修复 Codex Desktop 一直 Reconnecting 的问题。 + +请定位我本机正在使用的代理端口和代理协议，然后创建或更新 ~/.codex/.env，写入以下代理配置。不要写死 7890，请替换成实际端口；如果文件已经存在，保留其他配置。 + +HTTP_PROXY="http://127.0.0.1:" +HTTPS_PROXY="http://127.0.0.1:" +ALL_PROXY="socks5h://127.0.0.1:" +NO_PROXY="localhost,127.0.0.1,::1" + +写入后检查配置是否正确，并告诉我需要如何重启 Codex Desktop。 +``` + +如果你想手搓，那就用编辑器打开（或新建）`~/.codex/.env`，写入： + +>HTTP_PROXY="http://127.0.0.1:<端口，一般为 7890>" +>HTTPS_PROXY="http://127.0.0.1:<端口，一般为 7890>" +>ALL_PROXY="socks5h://127.0.0.1:<端口，一般为 7890>" +>NO_PROXY="localhost,127.0.0.1,::1" + +到这里，第一种情况基本就解决了。 + +--- + +第二种情况更隐蔽，也是我自己遇到的。 + +请求已经到达了服务器，但是服务器把请求给拒了。 + +image-20260602223806959 + +为什么会拒？如果你用的是 ChatGPT 账号，而账号开启了多因素认证（MFA），但 Codex 在初次认证时没有走完整的 MFA 流程，服务器就会把后续连接判定为未授权，直接断开。 + +这其实不是 Codex 的 Bug，而是 OpenAI 的安全策略在起作用：启用了 MFA 之后，一些旧 Session 或者不携带二次验证信息的连接会被强制失效。Codex Desktop 的登录状态恰好就可能因为缺少 MFA 验证而被踢下去，但又不会像网页端那样弹出二次验证提示，于是就卡在 Reconnecting 这个死循环里。 + +这种处理方式是 + +>开启 ChatGPT MFA，然后按 Cmd + Q 完全退出 Codex，再重新打开。 + +步骤如下： + +1. 打开 ChatGPT https://chatgpt.com/。 +2. 进入 Settings → Security。 +3. 在 Multi-factor authentication 下启用一种验证方式，例如验证器 App 或 Passkey。 +4. 完全退出 Codex Desktop：按 Cmd + Q。 + +别怀疑，官方也是这么说的。 + +![image-20260602224416532](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260602224416532.png) + +image-20260602231638652 + +我按照这个教程设置好 MFA，再把 Codex 完全退出重启后，就搞定了。 + +那个 Reconnecting 的提示再也没有出现过。 + +速度很快，非常丝滑。 diff --git "a/ai-articles/01-agent-and-coding/Codex \344\274\232\346\212\212\347\243\201\347\233\230\347\273\231\347\203\247\344\272\206\357\274\237\345\256\214\346\225\264\345\244\215\347\233\230\346\235\245\344\272\206\357\274\201.md" "b/ai-articles/01-agent-and-coding/Codex \344\274\232\346\212\212\347\243\201\347\233\230\347\273\231\347\203\247\344\272\206\357\274\237\345\256\214\346\225\264\345\244\215\347\233\230\346\235\245\344\272\206\357\274\201.md" new file mode 100644 index 0000000..eeb13f7 --- /dev/null +++ "b/ai-articles/01-agent-and-coding/Codex \344\274\232\346\212\212\347\243\201\347\233\230\347\273\231\347\203\247\344\272\206\357\274\237\345\256\214\346\225\264\345\244\215\347\233\230\346\235\245\344\272\206\357\274\201.md" @@ -0,0 +1,373 @@ +# Codex 会把磁盘给烧了？完整复盘来了！ + +[English](../../en/ai-articles/01-agent-and-coding/can-codex-wear-out-your-ssd-a-complete-investigation.md) | [中文](./Codex%20%E4%BC%9A%E6%8A%8A%E7%A3%81%E7%9B%98%E7%BB%99%E7%83%A7%E4%BA%86%EF%BC%9F%E5%AE%8C%E6%95%B4%E5%A4%8D%E7%9B%98%E6%9D%A5%E4%BA%86%EF%BC%81.md) + +> 日期：2026-06-24 + +这两天 Codex 圈子里有个说法挺吓人： + +高强度用 Codex，尤其是长时间跑 Agent，`~/.codex/logs_2.sqlite` 可能会持续写盘。文件看起来只是几百 MB，SSD 实际写入量可能已经被拉高很多。 + +我一开始也觉得这事儿有点夸张，直到我顺手查了一下自己的机器。 + +```text +~/.codex/logs_2.sqlite 约 823M +~/.codex/logs_2.sqlite-wal 约 38M +logs 表保留行数 61,418 +TRACE 估算内容 70.6 MiB +15 秒内 MAX(id) 增加 10,364 +保留行数变化 0 +``` + +本机 Codex logs_2.sqlite 排查数据图 + +*根据本机 `~/.codex/logs_2.sqlite` 只读采样整理* + +大家注意一下最后两行的数据。 + +表里保留的行数没变，`MAX(id)` 却在 15 秒内涨了一万多。 + +简单讲，Codex 还在不停的写新日志，同时把旧日志替换。虽然你看数据库没怎么变大，但磁盘已经被反复写了一轮又一轮了。 + +不过从实际情况上来讲，实时写日志本身很正常，保留最近一段日志也正常。 + +但是这次麻烦的是，很多 TRACE 级别的小事件也被写进本地 SQLite 了，写完还会删旧记录。表面只保留几万行，底层磁盘一直在干活。 + +所以现在的问题不是日志行数没有增加，也不是日志在飙升，相反，现在的核心是：**文件大小可能没怎么涨，SSD 写入量已经飙升了。** + +## 事情起因和经过 + +这不是一个单独网友的错觉。 + +2026 年 4 月 10 日，有用户在 OpenAI Codex 仓库提了 `#17320`。他观察到 Codex 在流式输出时，会持续往 `~/.codex/logs_2.sqlite-wal` 写数据，写入速度达到 MB/s 级别。 + +![image-20260623132408985](https://cdn.jsdelivr.net/gh/doggaifan/picbed@main/image-20260623132408985.png) + +5 月到 6 月，类似报告开始变多。 + +有人遇到 WAL 文件长期增长，删了也不释放空间，因为老的 Codex 进程还握着已经删除的文件句柄。 + +也有人在 Codex Desktop 正常使用几分钟后，看到 `logs_2.sqlite` 和 WAL 快速膨胀，界面也开始变慢。 + +社区报告中 logs_2.sqlite 体积异常的重绘图 + +*根据社区文章中的 Codex 本地状态检查截图整理* + +真正把事情推到台前的是 `#28224`。 + +image-20260623132541418 + +2026 年 6 月 14 日，有用户根据自己机器上的 SSD 写入量做了估算：21 天正常运行，主 SSD 写入约 37 TB。按这个速度折算，年化写入量接近 640 TB。 + +社区案例中 logs_2.sqlite 达到 38.2GB 的重绘图 + +*根据 X 讨论中的文件大小截图整理* + +这个数字只代表提出 issue 那台用户的机器，不代表每个人都会遇到同样规模。 + +但是他确实把问题直接抛出来了： + +**Codex 的本地诊断日志，在某些使用方式下确实可能持续写盘，甚至把 SSD 写入量堆到很夸张的位置。** + +风险最高的，是这几类一直在使用 Codex 的用户： + +- 长时间开着 Codex Desktop； +- 经常跑 `codex resume`； +- 让 Codex 做很长的流式（WebSocket 等）任务； +- 同时开多个 Codex / TUI / Desktop 进程； +- 机器用的是小容量 SSD、SD 卡、低耐久盘。 + +如果你一直隔一阵用一次 Codex ，或者你是 Codex 爱好者，并非 Codex 的深度用户来说，倒是还好。 + +但如果你把 Codex 当成你的兄弟，让它连续跑几个小时、几天不间断。 + +用 goal 或者 plan mode 给它上上强度的话，那你就得注意了。 + +## 问题现象 + +这次问题主要围绕三个文件： + +```text +~/.codex/logs_2.sqlite +~/.codex/logs_2.sqlite-wal +~/.codex/logs_2.sqlite-shm +``` + +这是 Codex 本地的 SQLite 日志库。 + +当 SQLite 开 WAL 模式后，写入通常先落到 `-wal` 文件里，再通过 checkpoint 合并回主库。 + +WAL 本身是正常机制。很多软件都这么用。 + +但是问题是 Codex 往里面记了太多不该写入的东西。 + +第一，流式返回里的成功事件也被记下来了。 + +模型正常输出一段文字、工具状态刷新一次、某个响应解析成功一次，都会成为日志。这样长任务一跑，每次调用之后的事件都会写入。 + +第二，之前很多 TRACE 日志会持久写到本地。 + +TRACE 是很细的排查日志，适合临时调试。如果你把它长期写进硬盘，尤其是写进 SQLite，就容易把写入量堆上去。 + +第三，它还会更新日志。 + +很多人看到表里只保留几万行，以为没啥大事儿。 + +但真实情况可能是：新日志一直插入，旧日志一直删除。导致最后的结果是日志一行没变，但是磁盘一直在写入。 + +这就是我本机采样看到的现象：15 秒内 `MAX(id)` 增加 10,364 行，但是表里总行数没有变。 + +为什么日志行数没涨但 SSD 还在写的解释图 + +*根据 OpenAI Codex issue / PR 和本机采样整理* + +## OpenAI 怎么处理的 + +这里有个关键变化：OpenAI 已经修了这次最主要的写盘问题。 + +我在 2026 年 6 月 23 日核对了官方仓库状态。2026 年 6 月 22 日，OpenAI Codex 仓库合并了两个相关 PR，作者是仓库 collaborator `jif-oai`。 + +`#29432` 处理的是：停止记录每个 Responses WebSocket 事件。 + +![image-20260623133530667](https://cdn.jsdelivr.net/gh/doggaifan/picbed@main/image-20260623133530667.png) + +`#29457` 处理的是另一个方向：过滤本地日志里的高噪音来源。 + +image-20260623133633698 + +也就是那些频率很高、平时排查价值不大的日志，不再默认写进本地 SQLite。 + +这两个修复合并后，`#28224` 已经在 2026 年 6 月 22 日关闭。同一天，GitHub Releases 页面也出现了 `rust-v0.142.0-alpha.11` 和 `rust-v0.142.0-alpha.12` 两个 alpha 预发布 tag。 + +![image-20260623134839585](https://cdn.jsdelivr.net/gh/doggaifan/picbed@main/image-20260623134839585.png) + +这里要跟大家说下：release 页面本身没有详细 changelog，所以只能把它当成“修复合并后出现的预发布版本”，不把它写成官方明确标注的修复公告。 + +到我核对时，`#17320`、`#22444`、`#24275` 这些相关 issue 仍然是 open 状态。它们还涉及 WAL 被老进程占住、删除后不释放空间、Desktop 日志库膨胀等问题。 + +所以目前比较准确的说法是： + +**最主要的高频 TRACE 写盘问题，官方已经合并修复。其它和 WAL 生命周期、老进程占用、健康提示有关的问题，还需要继续观察。** + +## 你现在该怎么做 + +普通用户先做一件事：升级 Codex。 + +尽量升级到包含 2026 年 6 月 22 日之后修复的版本。不同安装渠道的版本号可能不同，先看你自己的安装方式。 + +升级后再查本地文件。 + +**省流版** + +如果你懒得自己敲命令，可以直接把下面这段丢给 AI： + +````text +请帮我只读排查本机 Codex 的 ~/.codex/logs_2.sqlite 是否仍在因为 TRACE 日志或流式事件持续高频写盘。 + +约束： +1. 只做只读诊断。 +2. 不要删除文件，不要 VACUUM，不要 checkpoint/truncate，不要改 schema，不要创建 trigger，不要 kill 进程，不要升级或重装 Codex。 +3. 所有 SQLite 查询都用只读 URI：db="file:$HOME/.codex/logs_2.sqlite?mode=ro"。 +4. 如果 sqlite3、lsof 或数据库文件不存在，直接说明，不要猜。 +5. 最后请输出：是否疑似中招、证据、风险等级、下一步建议。 + +请按下面顺序执行并解释结果： + +第一步，确认文件大小： + +```bash +du -h \ + ~/.codex/logs_2.sqlite \ + ~/.codex/logs_2.sqlite-wal \ + ~/.codex/logs_2.sqlite-shm 2>/dev/null + +ls -lh ~/.codex/logs_2.sqlite* 2>/dev/null +``` + +第二步，只读检查 SQLite schema 和日志分布： + +```bash +db="file:$HOME/.codex/logs_2.sqlite?mode=ro" + +sqlite3 "$db" "PRAGMA table_info(logs);" + +sqlite3 "$db" " +PRAGMA journal_mode; +PRAGMA wal_autocheckpoint; +SELECT COUNT(*) AS rows, MIN(id), MAX(id) FROM logs; +SELECT level, COUNT(*) AS rows, ROUND(SUM(estimated_bytes)/1024.0/1024.0, 1) AS mib +FROM logs +GROUP BY level +ORDER BY SUM(estimated_bytes) DESC; +" +``` + +第三步，做 15 秒短窗口采样： + +```bash +db="file:$HOME/.codex/logs_2.sqlite?mode=ro" +before_id=$(sqlite3 "$db" "SELECT COALESCE(MAX(id),0) FROM logs;") +before_count=$(sqlite3 "$db" "SELECT COUNT(*) FROM logs;") +sleep 15 +after_id=$(sqlite3 "$db" "SELECT COALESCE(MAX(id),0) FROM logs;") +after_count=$(sqlite3 "$db" "SELECT COUNT(*) FROM logs;") +echo "id_delta=$((after_id-before_id))" +echo "count_delta=$((after_count-before_count))" +``` + +第四步，查看是否有 Codex 进程占着数据库或 WAL： + +```bash +lsof -nP \ + ~/.codex/logs_2.sqlite \ + ~/.codex/logs_2.sqlite-wal \ + ~/.codex/logs_2.sqlite-shm 2>/dev/null +``` + +判断标准： +- 如果 id_delta 很高，但 count_delta 很小或为 0，说明可能在持续插入又修剪旧日志。 +- 如果 logs_2.sqlite-wal 持续变大，或者有老 Codex 进程占着 deleted WAL，要重点提示。 +- 如果 id_delta 很低、WAL 不持续增长、只有当前 Codex 进程正常打开文件，就倾向于正常。 +- 不要直接给我执行修复操作。需要修复时，只列出方案和风险，等我确认。 +```` + +比如用了这段 prompt ，就检测到我的 codex 也中招了。 + +image-20260623142826935 + +这是不是能说明我是 Codex 的重度用户？ + +**手动版** + +如果你想手动排查一遍，也是可以的，下面是排查思路，你可以直接借鉴。 + +```bash +du -h \ + ~/.codex/logs_2.sqlite \ + ~/.codex/logs_2.sqlite-wal \ + ~/.codex/logs_2.sqlite-shm 2>/dev/null + +ls -lh ~/.codex/logs_2.sqlite* 2>/dev/null +``` + +再用只读方式看 SQLite 里到底写了什么： + +```bash +db="file:$HOME/.codex/logs_2.sqlite?mode=ro" +sqlite3 "$db" " +PRAGMA journal_mode; +PRAGMA wal_autocheckpoint; +SELECT COUNT(*) AS rows, MIN(id), MAX(id) FROM logs; +SELECT level, COUNT(*) AS rows, ROUND(SUM(estimated_bytes)/1024.0/1024.0, 1) AS mib +FROM logs +GROUP BY level +ORDER BY SUM(estimated_bytes) DESC; +" +``` + +这里用 `mode=ro`，意思是只读打开数据库。排查日志写盘问题时，尽量别让排查动作本身再去改数据库。 + +然后做一个短窗口采样： + +```bash +db="file:$HOME/.codex/logs_2.sqlite?mode=ro" +before_id=$(sqlite3 "$db" "SELECT COALESCE(MAX(id),0) FROM logs;") +before_count=$(sqlite3 "$db" "SELECT COUNT(*) FROM logs;") +sleep 15 +after_id=$(sqlite3 "$db" "SELECT COALESCE(MAX(id),0) FROM logs;") +after_count=$(sqlite3 "$db" "SELECT COUNT(*) FROM logs;") +echo "id_delta=$((after_id-before_id))" +echo "count_delta=$((after_count-before_count))" +``` + +如果升级后 `id_delta` 不再高速增长，WAL 也不再持续变大，就先别动数据库。 + +手动处理只适合两种情况：你还在旧版本上，或者升级后确认本机仍然在高速写入。 + +动手前先查有没有进程占着文件： + +```bash +lsof -nP ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite-wal ~/.codex/logs_2.sqlite-shm 2>/dev/null +``` + +如果有老 Codex 进程还在，先退出它。尤其是有进程握着 deleted WAL 时，你删文件也不一定马上释放空间。 + +然后备份： + +```bash +backup_dir="$HOME/.codex/logs_backup_$(date +%Y%m%d_%H%M%S)" +mkdir -p "$backup_dir" +find "$HOME/.codex" -maxdepth 1 -name 'logs_2.sqlite*' -exec cp -p {} "$backup_dir"/ \; +``` + +先退出、备份、止损、截断 WAL、观察增长的处理流程图 + +*根据社区 workaround 和 SQLite 清理建议整理* + +需要立刻止损时，社区里常见的临时方案是加一个 SQLite trigger，拦截 `logs` 表的新插入： + +```bash +sqlite3 ~/.codex/logs_2.sqlite " +CREATE TRIGGER IF NOT EXISTS block_log_inserts +BEFORE INSERT ON logs +BEGIN + SELECT RAISE(IGNORE); +END; +PRAGMA wal_checkpoint(TRUNCATE); +" +``` + +想撤销的话： + +```bash +sqlite3 ~/.codex/logs_2.sqlite " +DROP TRIGGER IF EXISTS block_log_inserts; +" +``` + +这个方案能临时止血，但它也会让 Codex 后续诊断日志不完整。真遇到问题要给官方反馈，日志可能少东西。 + +所以我的建议很简单： + +先升级。升级后再查。确认还在写，再备份后临时拦截。 + +## 我的看法 + +随着 AI 编程工具越来越像常驻系统服务之后，我们不仅要会使用 Coding Agent 这辆跑车来拉客，你还得学会定期给它保养。 + +因为它会开本地 server，会连 WebSocket，会记会话，会写运行数据，会管理后台任务。 + +这些能力叠起来之后，一个日志策略失误，就可能变成系统级别的资源问题。 + +以前我们担心 AI 写代码出 bug，但现在还得顺手看一眼 AI 工具本身有没有写爆磁盘。 + +这不是说 Codex 不能用。我也还在用。 + +但重度用户要养成一个习惯：**AI Agent 只要开始常驻，就要把它当成 AI Infrua 来看。** + +学会日常巡检。 + +对普通用户，它可能只是几百 MB 没多大用处的日志。 + +对重度用户，它可能真的关系到 SSD 寿命和系统稳定性。 + +虽然目前官方已经把主要 bug 改掉了，但是我们仍当保持清醒和警惕。 + +这就是我们能从这件事情中学到的教训。 + +--- + +参考来源： + +- [OpenAI Codex issue #17320](https://github.com/openai/codex/issues/17320) +- [OpenAI Codex issue #22444](https://github.com/openai/codex/issues/22444) +- [OpenAI Codex issue #24275](https://github.com/openai/codex/issues/24275) +- [OpenAI Codex issue #28224](https://github.com/openai/codex/issues/28224) +- [OpenAI Codex PR #29432](https://github.com/openai/codex/pull/29432) +- [OpenAI Codex PR #29457](https://github.com/openai/codex/pull/29457) +- [OpenAI Codex release 0.142.0-alpha.11](https://github.com/openai/codex/releases/tag/rust-v0.142.0-alpha.11) +- [OpenAI Codex release 0.142.0-alpha.12](https://github.com/openai/codex/releases/tag/rust-v0.142.0-alpha.12) +- [SQLite WAL 官方说明](https://sqlite.org/wal.html) +- [腾讯云开发者社区：Codex 5.5 用着用着变笨？先看本地这几个文件](https://developer.cloud.tencent.com/article/2676528) +- [SegmentFault：如何安全清理本地 Codex 对话历史？一个 CLI 工具的实现思路](https://segmentfault.com/a/1190000047816752) +- [X 讨论：Codex 流式传输与本地日志写入提醒](https://x.com/bdsqlsz/status/2067964486615810369) diff --git "a/ai-articles/01-agent-and-coding/Codex \345\244\247\346\233\264\346\226\260\357\274\232\344\273\216\345\206\231\344\273\243\347\240\201\345\267\245\345\205\267\345\217\230\346\210\220\350\203\275\346\223\215\344\275\234\344\275\240\347\224\265\350\204\221\347\232\204\345\212\251\346\211\213.md" "b/ai-articles/01-agent-and-coding/Codex \345\244\247\346\233\264\346\226\260\357\274\232\344\273\216\345\206\231\344\273\243\347\240\201\345\267\245\345\205\267\345\217\230\346\210\220\350\203\275\346\223\215\344\275\234\344\275\240\347\224\265\350\204\221\347\232\204\345\212\251\346\211\213.md" new file mode 100644 index 0000000..80ece9a --- /dev/null +++ "b/ai-articles/01-agent-and-coding/Codex \345\244\247\346\233\264\346\226\260\357\274\232\344\273\216\345\206\231\344\273\243\347\240\201\345\267\245\345\205\267\345\217\230\346\210\220\350\203\275\346\223\215\344\275\234\344\275\240\347\224\265\350\204\221\347\232\204\345\212\251\346\211\213.md" @@ -0,0 +1,90 @@ +# Codex 大更新：从写代码工具变成能操作你电脑的助手 + +> 日期：2026-04-18 + +Codex 迎来了重大更新，新推出了 `Computer use` 电脑助手这个功能，需要在 Mac 本地安装 Computer use 插件（Windows 估计也很快就推出了） + +你可以在 Codex 的桌面版上设置里面来安装 Computer use 。 + +image-20260418155533936 + +你可以直接借助计算机，Codex 可以查看和操作 macOS 上的图形用户界面。 + +它可以用于命令行工具或结构化集成不足以完成的任务，例如检查桌面应用程序、使用浏览器、更改应用程序设置、处理非插件形式的数据源，或重现仅在图形用户界面中出现的错误。 + +Codex 官方是这么形容的。 + +image-20260418100838365 + +如果你要在 Mac 上面安装，需要开启 + +1. **屏幕录制**权限，以便 Codex 可以看到目标应用程序。 +2. **授予辅助功能**权限，以便 Codex 可以点击、输入和导航。 + +不过只要你 Install Computer Use ，CodeX 会指引你进行安装的，非常丝滑。 + +![c4bd2859fd980a588df1eac79b73c05d](https://cdn.jsdelivr.net/gh/doggaifan/picbed/c4bd2859fd980a588df1eac79b73c05d.jpg) + +Computer use 解决了一个长期痛点：给那些没开放 API 的软件一点 GUI 级别的震撼。以前 agent 碰到这类应用就歇菜，现在 Codex 直接像人一样手动操作。 + +它的原理是：模型截取屏幕截图，理解界面内容，然后返回要执行的操作指令——"点击右上角按钮"、"在输入框填入 XXX"、"滚动页面"。这些操作交给 harness 执行，结果再截图回去，形成闭环。 + +这一波更新还加入了 90 多个插件，把 Atlassian Rovo、CircleCI、CodeRabbit、GitLab Issues、微软全家桶、Databricks 旗下的 Neon 等工具都接了进来。 + +## 实测：它到底能做什么 + +我让 Codex 自己回答了一下它都能做哪些事情。 + +af3e279b8998f87d6dd19279b3dc2e9b + +然后我让它演示了一下它风险最低的测试——让它看了一下系统的运行情况。 + +image-20260418154335455 + + + +演示了一下，让它给我媳妇发一条微信消息。 + +image-20260417204735178 + +甚至发一条朋友圈也不是什么问题。 + +image-20260418154419351 + +## 官方说：什么时候该用，什么时候不该用 + +OpenAI 官方文档里有一句重要提示： + +> Because computer use can affect app and system state outside your project workspace, use it for scoped tasks and review permission prompts before continuing. + +官方列出了适合用 Computer use 的场景： + +- 测试 macOS 应用、iOS 模拟器流程或其他桌面应用 +- 与没有 API 的软件交互 +- 重现只在图形界面里出现的 bug +- 更改应用设置 +- 处理没有插件形式的数据源 + +不适合的场景：涉及支付、删除大量数据等高风险操作，以及需要登录认证且无法人工确认的敏感操作。 + +## 我感觉它是 GUI 版 Claw + +OpenClaw 大家都知道——让 AI 控制你电脑的工具，鼠标、键盘、浏览器都能接管。好处是免费开源，坏处是配置麻烦，纯命令行，新人劝退。 + +而我感觉 Codex 内置的 Computer use ，就相当于是一个 GUI 版本的 Claw，不知道大家如何认为的，毕竟 OpenClaw 最为严厉的父亲 Peter 已经入职了 OpenAI，我认为这次的 Computer use ，就是以后 AI 会成为接管你个人 PC 的雏形。 + +Codex 现在就是这套逻辑的 GUI 版本——有界面、有项目隔离、有 Skills 扩展、有 Automations 自动化。OpenClaw 能做的它基本都有，还多了 OpenAI 原厂的支持和分发渠道。 + +Claude Code、Cursor 这些竞品都在往通用 Agent 的方向走。OpenAI 这次的策略很清楚：把 Codex 从编辑器里的编程助手，变成一个能跨应用、跨时间、跨工具链持续干活的数字同事。 + +这不是功能叠加，这直接是**定位迁移**了。 + +## 来源 + +- [Computer Use – Codex app - OpenAI Developers](https://developers.openai.com/codex/app/computer-use) +- [New Codex features include the ability to use your computer in the background - Ars Technica](https://arstechnica.com/ai/2026/04/new-codex-features-include-the-ability-to-use-your-computer-in-the-background/) +- [OpenAI expands Codex beyond coding with computer use, memory and plugins - Neowin](https://www.neowin.net/news/openai-expands-codex-beyond-coding-with-computer-use-memory-and-plugins/) +- [OpenAI's Codex Desktop can run your computer now - ZDNET](https://www.zdnet.com/article/openai-codex-desktop-update/) +- [Run long horizon tasks with Codex - OpenAI Developers](https://developers.openai.com/blog/run-long-horizon-tasks-with-codex) +- [OpenAI drastically updates Codex desktop app - VentureBeat](https://venturebeat.com/technology/openai-drastically-updates-codex-desktop-app-to-use-all-other-apps-on-your-computer-generate-images-preview-webpages/) +- [OpenAI Codex Update Adds Computer Use, Image Generation, and Plugins - MacRumors](https://www.macrumors.com/2026/04/16/openai-codex-mac-update/) diff --git "a/ai-articles/01-agent-and-coding/Codex \345\256\230\346\226\271\357\274\232goal \347\232\204\346\255\243\347\241\256\346\211\223\345\274\200\346\226\271\345\274\217.md" "b/ai-articles/01-agent-and-coding/Codex \345\256\230\346\226\271\357\274\232goal \347\232\204\346\255\243\347\241\256\346\211\223\345\274\200\346\226\271\345\274\217.md" new file mode 100644 index 0000000..13e9318 --- /dev/null +++ "b/ai-articles/01-agent-and-coding/Codex \345\256\230\346\226\271\357\274\232goal \347\232\204\346\255\243\347\241\256\346\211\223\345\274\200\346\226\271\345\274\217.md" @@ -0,0 +1,325 @@ +# Codex 官方：/goal 的正确打开方式 + +> 日期：2026-05-25 + +自从最后 Tibo 发了一条声明说修复了 Codex 订阅用量的 bug 之后，很明显的感觉是订阅掉的慢了。 + +以至于现在使用 `/goal` 这个模式，也可以稍微变得肆无忌惮了。 + +![image-20260525074929785](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260525074929785.png) + +等等，说到 /goal ，其实 Codex 官网上有一个非常实用的用法，下面就来跟大家聊聊。 + +--- + +Codex 官方对 /goal 有一句非常显眼的描述： + +>当任务需要 Codex 跨回合持续工作以达到可验证的停止条件时，请使用 /goal。 + +不是任何命令都适合用 /goal 模式，适合使用 /goal 的场景主要有： + +* 长时间运行的编码工作，具有明确的成功条件和验证循环。 +* 如果你的项目涉及代码迁移、大型重构、部署重试循环、实验、游戏和副项目，Codex 可以在这些项目中继续取得有范围的进展。 +* 需要开展具有明确成功标准的长期实验的团队。 + +上面这三点有一个明确的使用 /goal 的标准，大白话来说就是： + +**/goal 达成你希望 Codex 能够完成的最终目标，并通过具体可验证的方式来确认结果有效，同时保证遵守的限制条件不被破坏。** + +给大家举个适合使用 /goal 的例子： + +```prompt +## 给定清晰的边界目标 + +/goal 把这个 React 应用的登录页改成可用状态，修复当前报错，并确保 npm run build 通过。 + + +## 写明验收标准 + +完成标准： +- 登录表单能提交 +- 错误提示正常显示 +- 移动端布局不溢出 +- npm run lint 和 npm run build 都通过 + +## 给定条件边界 + +不要改后端接口；只改 src/app/login 相关文件。 + +## 给定优先级 + +优先保证功能可用，其次再美化 UI。 +``` + +这个是你知道使用 /goal 来做什么的情况下。具有明确的目标和可验证条件。 + +那如果你不知道使用 /goal 来做什么，还适合用这个 slash 吗？ + +也是可以的。 + +/goal 还适用一种场景是开放式探索，就是你不知道你要做啥的时候，/goal 仍旧能顶上。 + +比如 + +![image-20260525081205431](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260525081205431.png) + +当然这个例子有点极端了。 + +![image-20260525093040293](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260525093040293.png) + +不过呢，你让他做一个百度或者阿里倒是可以的。 + +![image-20260525093409528](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260525093409528.png) + +这突然让我想到了，古法编程时期的很多需求，如今看来，确实可以成为落地的需求。 + +--- + +如果你在 Codex 上输入 /goal 没有看到斜杠命令在列表中出现的话，那你需要在 `config.toml` 中启用 `features.goals`。 + +```toml +[features] +goals = true +``` + +你也可以在 Codex Cli 中运行启动 /goal 。 + +/goal 的用法比较简单，目前支持 + +```bash +/goal pause ## 暂停执行目标 +/goal resume ## 暂停恢复目标 +/goal clear ## 清除执行目标 +``` + +上面提到了使用 goal 的场景和使用方式，如果你要使用 /goal ，你需要建立一个工作契约： + +1. 指定一个目标和一个停止条件。 +2. 告诉 Codex 先读哪些文件、文档、issue、日志或计划。 +3. 定义哪些命令或产物可以证明进展。 +4. 要求 Codex 分 checkpoint 工作，并保留简短进度记录。 +5. 运行时用 /goal 查看状态 +6. 当完成、阻塞或方向改变时，用 pause、resume 或 clear 控制它。 + +这里给大家一个实操建议，千万不要一个 /goal 命令一路走到黑，我之前也使用 /goal 执行过一个 75h 的命令，但其实收益与时间损耗系数并不成正比。 + +f127f7f7a0e464e7af71159653da1442 + +你在使用 goal 的时候，最好让 goal 给 Codex 一份紧凑的进度报告，定期报告状态更新操作，包括 + +* 当前的 checkpoint； +* 已验证的内容； +* 剩余工作； +* 是否被阻塞。 + +如果状态报告变得含糊，不要一直加零散指令，而是收紧 goal：明确下一个 checkpoint、用哪个命令证明完成、什么情况应该暂停。 + +官方文档的定位是：/goal 更像一个后台任务。你给它清楚目标后，它可以长时间独立工作，并在确信达到停止条件时停下。 + +这里有几个示例，大家可以参考 + +技术栈迁移： + +```prompt +/goal 把这个项目从 [旧技术栈] 迁移到 [目标技术栈]。确保所有页面视觉表现保持一致，并用 Playwright 验证输出。 +``` + +原型创建： + +```prompt +/goal 按 PLAN.md 实现第一版，为每个里程碑创建测试，并用 Playwright 验证输出。必要时参考给定截图。 +``` + +提示词优化： + +```prompt +/goal 优化 [提示词文件或目录]，直到 eval 套件达到 [目标分数或通过率]。每次修改后运行 [eval 命令]，检查失败样例，并保持改动小而精准。达到目标，或后续修改需要产品/政策判断时停止。 +``` + +--- + +说实话，我现在觉得 /goal 最适合搭配的东西，是一份 PRD 或者 spec。 + +因为 /goal 本质上解决的是持续执行的问题。 + +但持续执行有一个前提： + +**它必须知道自己到底在持续执行什么。** + +如果你只是丢一句： + +```prompt +/goal 根据 PRD 把这个功能做完 +``` + +那基本上就等于你把一个大方向交给 Codex，然后让它自己猜哪些是必须做的，哪些是可以不做的，哪些地方遇到冲突应该停下来问你。 + +这种做法风险比较大。 + +尤其是 PRD 这种文档，很多时候写的是「产品意图」和「用户体验」，里面会有大量类似： + +* 用户希望可以更方便地完成某个流程； +* 页面需要足够清晰； +* 交互尽量自然； +* 后续可以支持某个能力。 + +这些描述对人来说很好理解，但对 Codex 来说，如果没有验收标准，很容易跑偏。 + +所以我比较推荐的做法是，不要直接让 /goal 依照 PRD 直接开干，而是让 PRD 和 spec 结合输出一份执行蓝图。 + +大概是这样： + +```prompt +/goal 根据 docs/PRD.md 和 docs/SPEC.md 实现 [功能名]。 + +开始前先阅读这两个文档，并整理出： +1. 必须实现的需求 +2. 明确不做的非目标 +3. 需要验证的验收标准 +4. 可能存在歧义或冲突的地方 +5. 建议的 checkpoint 执行顺序 + +如果 PRD 和 SPEC 有冲突，先暂停并说明，不要自行决定。 +每完成一个 checkpoint 后运行对应测试。 +只有当所有验收标准满足、构建通过、关键流程验证完成时才停止。 +``` + +这段 prompt 的重点在先把大作文拆成 checklist，再开始执行。 + +我自己的使用经验是，PRD 和 spec 最好分工明确： + +* PRD 负责告诉 Codex：为什么要做、用户是谁、核心流程是什么、体验上不能偏离什么。 +* spec 负责告诉 Codex：接口怎么设计、数据怎么流转、边界条件有哪些、哪些测试必须通过。 +* /goal 负责把这两份文档变成一个可以持续推进的执行循环。 + +一句话总结就是： + +```text +PRD 决定方向，spec 决定边界，/goal 负责推进和验证。 +``` + +这三个东西配合好了，Codex 的执行质量会明显稳定很多。 + +我之前踩过一个坑，就是把 PRD 写得很完整，然后直接让 /goal 去实现。结果 Codex 的确很努力，但它会把一些 TODO 也当成当前版本需求来做。 + +比如 PRD 里写了一句： + +> 后续可以考虑支持多租户配置。 + +它可能真的会开始设计多租户的数据结构。 + +你说它错了吗？ + +也不完全错，因为文档里确实出现了这个方向。 + +但这显然不是当前阶段应该做的事情。 + +所以后来我会在 goal 里面加一句非常重要的话： + +```prompt +PRD 中出现的「后续」「未来」「可以考虑」「可扩展」内容，默认都视为非目标，除非 SPEC 或完成标准明确要求实现。 +``` + +这个小限制非常有用，可以显著减少 Codex 的过度发挥。 + +如果你手上只有 PRD，没有 spec，我建议不要直接开 /goal 实现，而是先让 Codex 生成一份轻量 spec。 + +比如： + +```prompt +阅读 docs/PRD.md，先不要写代码。 +请把它整理成一份 implementation spec，包含： +- 当前版本必须实现的功能 +- 不做的非目标 +- 数据结构和状态流转 +- UI 页面和关键交互 +- 验收标准 +- 测试建议 +- 需要我确认的问题 +``` + +等这份 spec 确认之后，再开 /goal。 + +这样会比边读 PRD 边写代码要稳定很多。 + +如果你已经有 PRD 和 spec，那就可以更激进一点，直接让 /goal 开始跑。 + +我比较常用的完整模板是这个： + +```prompt +/goal 按照 docs/PRD.md 和 docs/SPEC.md 完成 [功能名] 的第一版实现。 + +执行规则： +- PRD 是产品目标和用户流程的来源 +- SPEC 是技术实现和接口契约的来源 +- 如果两者冲突，以 SPEC 为准，但必须在进度报告中说明 +- PRD 中的未来规划默认不实现 +- 不要修改与本功能无关的模块 + +工作方式： +- 先整理需求 checklist 和 checkpoint +- 每个 checkpoint 完成后运行相关测试 +- 如果涉及页面，使用浏览器验证主要流程 +- 如果构建或测试失败，优先修复失败项 + +完成标准： +- PRD 中当前版本核心流程全部可用 +- SPEC 中定义的接口、状态、边界条件全部满足 +- npm run test 通过 +- npm run build 通过 +- 关键页面或流程完成实际验证 + +停止条件： +- 所有完成标准满足后停止 +- 遇到产品判断、文档冲突或需要扩大范围时暂停并说明 +``` + +这个模板看起来有点长，但实际用起来很省心。 + +因为这其实把「能不能改」「做到什么程度」「什么时候停」「遇到冲突怎么办」都提前说清楚了。 + +这其实就是 /goal 最吃香的地方。 + +普通对话里，Codex 往往是你问一轮，它做一步。 + +但 /goal 更像是你给它一张施工图，再告诉它验收方式，它自己按阶段往前推。 + +当然，这里也有一个很现实的建议： + +**不要让一个 /goal 承包整个巨大 PRD。** + +如果你的 PRD 里面有用户系统、支付系统、后台管理、消息通知、数据看板，那最好不要写： + +```prompt +/goal 根据 PRD 完成整个系统 +``` + +这个很容易变成超长时间任务，而且后面状态会越来越难判断。 + +更好的方式是把 PRD 拆成多个 goal： + +```prompt +/goal 按 PRD 和 SPEC 完成登录注册模块，完成后通过认证相关测试和页面验证。 +``` + +```prompt +/goal 按 PRD 和 SPEC 完成订单创建流程，暂不处理支付回调。 +``` + +```prompt +/goal 按 PRD 和 SPEC 完成支付回调和订单状态流转，确保相关测试通过。 +``` + +这样每一个 goal 都有清晰边界，也方便你随时 pause、resume、clear。 + +最后给大家一个我自己的判断标准： + +如果一个任务可以用一句话说完，并且十分钟内能完成，那就没必要开 /goal。 + +如果一个任务需要反复读文档、改代码、跑测试、看页面、修失败项，那就非常适合 /goal。 + +如果这个任务还有 PRD 和 spec，那就更适合。 + +因为这时候 /goal 不是在帮你猜需求，而是在帮你执行已经定义好的需求。 + +这才是它真正好用的地方。 diff --git "a/ai-articles/01-agent-and-coding/Codex \346\212\212\346\210\221\345\256\266\347\275\221\347\273\231\344\274\230\345\214\226\344\272\206\357\274\214\346\210\221 TM \347\233\264\346\216\245\345\216\237\345\234\260\350\265\267\351\243\236\344\272\206\343\200\202.md" "b/ai-articles/01-agent-and-coding/Codex \346\212\212\346\210\221\345\256\266\347\275\221\347\273\231\344\274\230\345\214\226\344\272\206\357\274\214\346\210\221 TM \347\233\264\346\216\245\345\216\237\345\234\260\350\265\267\351\243\236\344\272\206\343\200\202.md" new file mode 100644 index 0000000..fd7cd46 --- /dev/null +++ "b/ai-articles/01-agent-and-coding/Codex \346\212\212\346\210\221\345\256\266\347\275\221\347\273\231\344\274\230\345\214\226\344\272\206\357\274\214\346\210\221 TM \347\233\264\346\216\245\345\216\237\345\234\260\350\265\267\351\243\236\344\272\206\343\200\202.md" @@ -0,0 +1,70 @@ +# Codex 把我家烂网给优化后，我 TM 直接原地起飞了。 + +> 日期：2026-05-24 + +昨天看到一个非常有意思的事情，有人研究了一下用 Codex 直接把家里网络修复了一下，修复之后的网络直接原地起飞，实测速度堪比光速。 + +image-20260524111109592 + +这本来没啥可说的。 + +但后面有意思的是，另外一个网友直接把原贴扔给了 Codex ，随后附上了自己的 prompt + +```prompt +Hey my friend says he improved his internet speed and here is what happened. Can you check if there are any improvements we can make for our internet? My provider says they're sending 1.2k gbps and anything I get is a result of hardware. I'm getting 55mbps right now pls fix make no mistakes. +``` + +这句话的意思是说。 + +>我朋友说他的网速提高了，情况是这样的。你能帮我看看我们家的网络有什么可以改进的地方吗？我的网络供应商说他们提供的带宽是 1.2k Gbps，而我实际的网速是硬件问题导致的。我现在只有 55Mbps，请帮我解决这个问题，别出任何差错。 + +然后放了一下优化前和优化后的实测对比图。 + +image-20260524070446799 + +这哥们的聪明之处在于，他直接把“别人成功优化的真实案例”当作上下文喂给 Codex，让 Codex 参考那个案例，给自己当前的烂网速做针对性诊断和修复。 + +也就是说，只要有人从 0 -> 1 真实跑通一个案例，你发出来之后其他人就可以很方便的裂变，变成 1 -> N。 + +>这里我有个问题，为什么这个人的成功经验不是直接让 LLM 来直接回答呢（手动狗头） + +然后 x 上确实有很多人通过这种方式优化了网络性能。 + +我自己也根据这个 prompt 进行了实操，确实网络直接原地起飞了。一条要求 Codex 针对网速改善的对比的请求，工作了 25s 就完成了。 + +503bd396-8462-490f-afd7-5279e99964d8 + +然后这是优化之后的直观对比。 + +![image-20260524070258122](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260524070258122.png) + +看起来效果提升的并不是特别明显，但我从用户亲身体验的角度来说，确实达到了直接原地起飞的效果。 + +要知道，我肉身是在国内。。。。。。 + +使用这种方式记得有一点，先评估再进行操作，先让 LLM 做好执行备份。否则容易把你的 xx 给直接 kill 掉。 + +比如这个哥们的操作就直接给我笑麻了。 + +image-20260524102218162 + +我自己实测的过程中也出现过 codex 乱杀的情况，但是幸好我这个影响不太大。 + +--- + +直接给出大家 prompt 好了，你可以直接去 agent 上（任何 LLM 都可以尝试）进行修复。 + +```prompt +诊断问题：首先运行了 speedtest-cli。 +> 检查了 DNS 解析时间， +> 检查了 MTU、数据包丢失、Wi-Fi 信号/干扰。 +> 发现了 3 个问题。 +> 删除了过期的网络位置/配置文件。 +> 终止或限制了占用带宽的后台进程。 +> 优化了 mDNS。 +> 运行了前后速度测试和延迟检查。 +``` + +有人使用 `/goal` 命令直接修复，我没有使用 /goal 命令，不过修复的也不错。 + +希望大家都能体会到网速起飞的酥麻感，简直太爽了。 diff --git "a/ai-articles/01-agent-and-coding/Codex \347\232\204\346\241\214\351\235\242\347\211\210\345\256\240\347\211\251\346\257\224 CC \347\232\204\345\245\275\347\224\250\345\244\232\344\272\206 - \346\226\260\347\250\277.md" "b/ai-articles/01-agent-and-coding/Codex \347\232\204\346\241\214\351\235\242\347\211\210\345\256\240\347\211\251\346\257\224 CC \347\232\204\345\245\275\347\224\250\345\244\232\344\272\206 - \346\226\260\347\250\277.md" new file mode 100644 index 0000000..cbeee9c --- /dev/null +++ "b/ai-articles/01-agent-and-coding/Codex \347\232\204\346\241\214\351\235\242\347\211\210\345\256\240\347\211\251\346\257\224 CC \347\232\204\345\245\275\347\224\250\345\244\232\344\272\206 - \346\226\260\347\250\277.md" @@ -0,0 +1,472 @@ +# Codex 的桌面宠物，比 Claude Code 的好用多了 + +> 日期：2026-05-08 + +一开始我看到 Codex 桌面宠物的时候，内心是拒绝的。 + +不是说它不好看，而是我对这种东西有天然偏见。 + +什么桌宠、挂件、电子宠物、Q 版 mascot，在我脑子里基本都属于同一个分类： + +> 看着热闹，用处不大。 + +尤其是前面 Claude Code 也搞过类似的宠物，我玩了一下，感觉更多是一个彩蛋系统。抽一个宠物，挂在那里，给你一点情绪价值。你说它没用吧，也不是完全没用；你说它有用吧，又很难说服自己真的有用。 + +所以 Codex 上线这个桌面宠物之后，我并没有第一时间去玩。 + +直到今天群里有个读者朋友问我： + +> 你怎么没玩 Codex 的桌面宠物？ + +我当时还挺疑惑。 + +这玩意有什么好玩的？ + +然后他给我发了一个视频。 + +我看完第一反应是：哦，这不就是一个 skill 的事儿吗？一分钟搞定。 + +一分钟之后。 + +我沉默了。 + +因为这东西不是我想象中的“卖萌挂件”。 + +**这玩意儿，还真有用。** + +--- + +## 它表面是宠物，本质是一个悬浮状态面板 + +先说怎么用。 + +在 Codex 里找到 skills，搜索 Hatch Pet。 + +![image-20260508161507350](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260508161507350.png) + +默认角色是一只蓝色 Q 版电脑人，非常符合 Agent 产品的审美：可爱、无害、像一个刚刚学会干活的小工具人。 + +fc268ab04adfe3f4429b079e23231775 + +它的气质有点像《爱，死亡和机器人》第一季第二集里的那个小机器人。 + +image-20260508163736839 + +如果只是这样，那我大概率看两眼就关了。 + +但 Codex 这个宠物真正有意思的地方在于：它不是一个单纯的装饰物。 + +它是一个浮在桌面上的工作状态入口。 + +当 Codex 有任务在跑的时候，它可以显示当前任务状态；当有需要你处理的上下文时，它可以弹出提示；你甚至可以直接通过它做快捷回复。 + +image-20260508164044488 + +这个点，对多任务用户非常重要。 + +现在的 AI Agent 不再是“你问一句，它答一句”的玩具形态。它越来越像后台工人：你给它一个任务，它去跑命令、改文件、查资料、等结果、再回来找你确认。 + +问题来了：当你同时开几个线程、几个项目、几个 Agent 的时候，你怎么知道谁正在干活，谁卡住了，谁需要你回一句话？ + +传统 CLI 的体验是：你得回到那个窗口里看。 + +Codex 这个桌宠的价值就在这里。 + +它把 Agent 的状态从“窗口内部”提到了“桌面表层”。 + +--- + +## 它能做什么，不能做什么 + +先把边界说清楚。 + +Codex Pet 不是另一个 AI 助手。 + +它不能自己聊天，不能替你写代码，不能独立调用 API，也不能像插件那样给 Codex 增加新能力。 + +它真正能做的是这些： + +- 待机陪伴：平时在桌面上显示一个小角色，有 idle 动画。 +- 表现状态：运行、等待、失败、审阅、跳跃、挥手，不同状态可以切换不同动作。 +- 任务提醒：当 Codex 有活动或需要你关注时，它可以作为浮窗入口。 +- 快捷回复：某些场景下可以直接在浮窗里处理消息。 +- 自定义形象：可以把它做成小猫、小机器人、小火球、植物、鸭子，或者你指定的角色风格。 +- 本地安装：打包后放到 `~/.codex/pets//`，Codex 就能识别。 + +这也是它比 Claude Code 那套宠物更让我愿意玩的地方。 + +Claude Code 的 CLI 宠物更像游戏彩蛋，有稀有度，有抽卡感。普通宠物大概率就是 common，看两眼就索然无味。 + +当然，我也不是没折腾过。 + +我甚至还撸过一个 buddy 重抽，可以直接抽金色品质宠物： + +https://github.com/crisxuan/buddy-reroll + +但说实话，那个方向本质上还是“抽到一个更好看的东西”。 + +Codex 这边不一样。 + +它的宠物不只是皮肤，它和桌面端的任务状态连上了。 + +也就是说，它有一点点“产品入口”的味道。 + +别小看这点。 + +一个东西从“装饰”变成“入口”，性质就变了。 + +--- + +## 然后我开始给它整 2B + +默认蓝色小人虽然不错，但这玩意儿都支持自定义了，我怎么可能只用默认款。 + +我比较喜欢《尼尔：机械纪元》里的角色，所以第一反应就是：整一个 2B。 + +Hatch Pet 默认生成的风格比较偏 Q 萌。 + +比如这样： + +image-20260508134254072 + +不是说不好。 + +但这完全不符合我对 2B 的人物理解。 + +2B 是什么？冷感、克制、黑色礼服、战斗人偶、压迫感和优雅感并存。 + +你给我整成 Q 萌小手办，这就不对味了。 + +我不允许。 + +于是我重新描述角色风格，强调不要 Q 版，要更接近原版比例，更御姐一点，更有黑色哥特礼服和机械感。 + +然后就出了这个版本： + +image-20260508134537875 + +这就对了。 + +审美终于在线了。 + +说实话，GPT-image-2 在这种角色审美上的能力确实很强。。。。。。 + +但是还有一个问题。 + +桌宠不适合带背景。 + +带一块背景板浮在桌面上，看起来就很像网页截图被硬塞进桌面，廉价感立刻上来了。 + +所以我又让它生成透明背景版本。 + +image-20260508140747053 + +然后熟悉的事情发生了。。。。。。风格漂移了。。。。。。 + +你让它去掉背景，它顺手把人物味道也换了。 + +这就是生成图最烦人的地方：你以为自己只改 A，它顺手把 B、C、D 也全改了。 + +于是我继续 PUA 它，强调保持上一版人物风格，只处理透明背景，不要改脸，不要改比例，不要改服装气质。 + +终于得到了我想要的版本： + +image-20260508141002744 + +到这里，我已经开始上头了。 + +这不比蓝色小电脑人有意思多了？ + +直接当桌面宠物。 + +![image-20260508141613077](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260508141613077.png) + +装上以后，我发现了一个非常严重的问题。 + +2B 最重要的是什么？那必须得是腿。 + +结果桌面宠物显示出来，下半身被裁掉了，这必须忍不了。 + +一开始我以为问题出在宠物素材包。 + +Hatch Pet 的标准格式是一个 `8x9` 的 spritesheet，每一格是 `192x208`。不同的行对应不同状态，比如 idle、running、waiting、failed、review 等。 + +宠物包本身确实能控制角色在格子里占多少，也能决定透明背景、帧排列、状态动画。 + +但它控制不了桌面端最终把这个宠物显示多大。 + +这就是第一层坑。 + +Hatch Pet 管的是“宠物资产怎么生成、怎么打包、怎么被 Codex 识别”。 + +桌面端显示层管的是“这个宠物浮窗多大、外层容器多大、主进程怎么测量和摆放”。 + +这两个不是一回事。 + +我前面就是把这两件事混在一起了。 + +于是我开始改 Codex 桌面端。 + +这一步，普通用户真的别学。 + +我当时的想法很简单：既然 CSS 里写着 `width: 7.04rem`，那我把它改成三倍，比如 `21.1rem`，不就完事了吗？ + +事实证明，事情没这么简单。 + +更精彩的是，我还把 Codex 改崩了。 + +一打开就崩。 + +传出去就是： + +> Codex 把自己玩死了。 + +--- + +## Codex 为什么会被我改崩 + +一个兄弟挂了，只能让另一个兄弟上。 + +CC，启动。 + +我让 Claude Code 帮我分析崩溃原因。 + +![image-20260508144250046](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260508144250046.png) + +排查过程很长，我就不展开折磨大家了。 + +直接说结论： + +我在 `dangerFullAccess` 和 `approvalPolicy: never` 的权限下，让 Codex 直接修改了 `/Applications/Codex.app/Contents/Resources/app.asar` 里的 CSS。 + +问题是 Electron App 的 `app.asar` 不是普通文件。 + +你改了它，`Info.plist` 里的 ASAR 完整性 hash 也要同步更新，否则 Electron 启动时会发现 hash 不匹配，然后直接 FATAL。 + +也就是说，CSS 本身不是罪魁祸首。 + +真正让 Codex 起不来的，是： + +> 改了 ASAR，但没有同步完整性校验。 + +这就像你把保险柜里的文件偷偷换了，但封条还贴着旧编号。系统一开门，发现编号不对，直接报警。 + +后来修复方式也很明确： + +- 备份原始 `app.asar` +- 修改 ASAR +- 重新计算 hash +- 写回 `Info.plist` +- 重新 codesign +- 准备 rollback 脚本 + +这一步之后，我才敢继续折腾。 + +因为最怕的不是改错。 + +最怕的是改错以后没退路。 + +--- + +## 只改 `21.1rem` 为什么没用 + +修好以后，我继续尝试把宠物放大。 + +我先把 `codex-avatar-root` 从 `7.04rem` 改到 `21.1rem`。 + +理论上应该变大三倍。 + +结果没变。 + +这就很离谱。 + +我让 Codex 继续排查，最后终于抓到了幕后黑手。 + +整个链路是这样的： + +1. `codex-avatar-root` 的 CSS 宽度确实被改成了 `21.1rem`。 +2. 但它外面还有一层 React wrapper。 +3. 这层 wrapper 的 class 写死了 `size-20`。 +4. 在 Tailwind 里，`size-20` 大约就是 `80px x 80px`。 + +所以之前的情况其实是： + +> 里面的图想变大，外面的盒子不让它变大。 + +更关键的是，Codex 桌面端主进程会根据这个 wrapper 的实际尺寸来摆放宠物。 + +当时全局状态里已经能看到证据： + +```json +{ + "width": 712, + "height": 640, + "mascot": { + "width": 80, + "height": 87 + } +} +``` + +这说明外层窗口已经变大了，但宠物本体测量出来还是 `80x87`。 + +真正限制大小的不是 `codex-avatar-root`。 + +而是 `data-avatar-mascot` 那层 wrapper。 + +最后真正生效的修复是把： + +```text +relative flex size-20 ... +``` + +改成类似： + +```text +relative h-96 w-80 ... +``` + +也就是让宠物本体容器从约 `80x80` 放大到约 `320x384`。 + +这一步之后，桌宠才真正变大。 + +所以这次最有意思的地方不是“我把宠物放大了”。 + +而是它暴露了一个很典型的前端问题： + +> 你看到的那个样式，未必是最终限制你的那个样式。 + +很多时候你改了子元素，父容器还在掐脖子。 + +这事儿写前端的人应该都懂。 + +--- + +## 但这里要说清楚：我这不是 Hatch Pet 的标准玩法 + +严格来说，我后面这些操作，已经不是 Hatch Pet 的正统流程了。 + +Hatch Pet 的原始逻辑是： + +> 从 concept、reference images 或二者结合开始，用 Image Gen 生成 base，再生成带参考约束的每一行动画 row strip，先生成 running-right，再判断 running-left 是否可以安全镜像，然后用 skill 自带的 deterministic scripts 去 ingest、validate、assemble spritesheet，最后打包到 `${CODEX_HOME:-$HOME/.codex}/pets//`。 + +也就是说，Hatch Pet 正规做的是一条资产生成流水线。 + +它关心的是： + +- 角色是谁 +- 每个状态怎么动 +- 每一帧有没有越界 +- spritesheet 是否符合 `8x9` +- `pet.json` 是否正确 +- 能不能被 Codex 识别 + +而我后面做的是另一条线： + +- 改 Codex App 的显示尺寸 +- 改 React wrapper +- 改 overlay 主进程几何 +- 改 ASAR hash +- 重新签名 + +这已经是桌面端显示层改造了。 + +所以如果你只是想做一个正常宠物，不要学我这样改 App。 + +你应该老老实实走 Hatch Pet 的标准流程。 + +但如果你的诉求是“我要让桌面宠物在屏幕上整体变大”，那 Hatch Pet 本身解决不了，因为它只负责宠物资产，不负责 Codex 桌面端怎么显示这个资产。 + +这就是这次折腾最重要的结论。 + +--- + +## 为什么我说 Codex 这个宠物比 CC 的好用 + +因为它不只是情绪价值。 + +情绪价值当然有。 + +默认蓝色小人很可爱，自定义成 2B 也很爽。 + +但真正让我觉得它有价值的，是它和 Codex 的工作流连在了一起。 + +它能告诉你任务在跑。 + +它能提醒你哪里需要处理。 + +它能作为一个浮在桌面上的轻量入口。 + +这就让它从“宠物”变成了“Agent 工作状态的可视化外壳”。 + +Claude Code 的宠物更像一个彩蛋。 + +Codex 的宠物更像一个 UI 层。 + +彩蛋会腻。 + +UI 层不会。 + +因为只要你的工作流还在，它就还有存在价值。 + +这也是为什么我一开始看不上它，后来又真香。 + +它不是因为可爱才值得玩。 + +它是因为刚好站在了一个非常微妙的位置： + +> Agent 越来越后台化，而用户需要一个前台感知层。 + +桌面宠物就是这个前台感知层的一种形态。 + +你可以觉得它幼稚。 + +但你不能否认，它确实解决了一部分“我不知道 Agent 现在在干嘛”的问题。 + +--- + +## 最后 + +这次折腾下来，我对 Codex 桌面宠物的评价变了。 + +一开始我以为它是一个玩具。 + +后来发现它是一个状态入口。 + +再后来我把它改崩了。 + +最后我意识到，它其实暴露了 Codex 桌面端产品设计里一个很有意思的方向： + +AI Agent 不能永远躲在终端里。 + +它需要有状态。 + +需要有存在感。 + +需要在你不盯着它的时候，也能告诉你“我还在干活”“我卡住了”“你该回我了”。 + +这不是简单的萌宠问题。 + +这是 Agent 产品形态的问题。 + +当然，做自定义宠物也是真的费额度。 + +我这次是因为领了 GPT 给我的 Pro 20x 权益，所以才能一路猛夯。 + +![image-20260508133941909](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260508133941909.png) + +普通用户慎重。 + +别看我这里写得轻松，背后其实是： + +生成图反复漂移、透明背景反复调、spritesheet 要符合格式、桌面端还可能被你改崩。 + +但话又说回来。 + +这不就是 AI 工具现在最有意思的地方吗？ + +它不是完美产品。 + +它是一个可以被你当场掰开、重组、改坏、修好、再继续玩的东西。 + +这才叫真的好玩。 diff --git "a/ai-articles/01-agent-and-coding/Codex \350\277\233\346\211\213\346\234\272\344\272\206\357\274\214\350\277\231\346\211\215\346\230\257 Agent \350\257\245\346\234\211\347\232\204\347\247\273\345\212\250\347\253\257.md" "b/ai-articles/01-agent-and-coding/Codex \350\277\233\346\211\213\346\234\272\344\272\206\357\274\214\350\277\231\346\211\215\346\230\257 Agent \350\257\245\346\234\211\347\232\204\347\247\273\345\212\250\347\253\257.md" new file mode 100644 index 0000000..3087b79 --- /dev/null +++ "b/ai-articles/01-agent-and-coding/Codex \350\277\233\346\211\213\346\234\272\344\272\206\357\274\214\350\277\231\346\211\215\346\230\257 Agent \350\257\245\346\234\211\347\232\204\347\247\273\345\212\250\347\253\257.md" @@ -0,0 +1,181 @@ +# Codex 进手机了，这才是 Agent 该有的移动端 + +> 日期：2026-05-15 + +OpenAI 在 2026 年 5 月 14 日发布了一篇新文章：[Work with Codex from anywhere](https://openai.com/index/work-with-codex-from-anywhere/)。 + +这次更新的核心很简单：Codex 进入 ChatGPT 移动应用了。 + +![Codex mobile preview](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260515054025761.png) + +从产品形态看，它不是一个新的独立 App，而是直接出现在 ChatGPT 的 iOS 和 Android 客户端里。目前是 preview，面向所有受支持地区推出，并覆盖所有计划，包括 Free 和 Go。 + +要使用它，需要更新 ChatGPT 移动应用和 Codex macOS app。设置入口在 Codex 桌面侧边栏。Windows 支持还没正式上线，官方说 soon。 + +![Codex desktop connect](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260515054802649.png) + +听起来像一个“小功能”，但我觉得这其实是 Codex 产品形态里很关键的一步。 + +因为 Agent 真正开始承担长任务之后，问题不再只是“它会不会写代码”，而是“它工作到一半，需要我出现的时候，我能不能马上出现”。 + +## 它不是远程桌面 + +很多人看到 Codex 移动版，第一反应可能是：这不就是远程控制电脑吗？ + +不是。 + +远程桌面解决的是你能不能在手机上操作电脑。Codex 移动端解决的是你能不能在手机上接管 Agent 工作流。 + +这两个差别很大。 + +OpenAI 这次的设计是：手机端连接到运行 Codex 的机器，可以是你的笔记本、开发机，也可以是远程环境。手机加载的是这些环境里的实时状态，而不是把代码、密钥和依赖都搬到手机上。 + +真正执行任务的地方仍然是原来的机器。 + +你的文件、凭据、权限、本地设置都保留在那里。手机端只是让你查看线程、输出、截图、终端结果、diff、测试结果和审批状态。 + +这个设计很合理。 + +手机不适合成为开发环境，但很适合成为决策界面。 + +## 它解决的是“中途卡住” + +Codex 这种 Agent 做长任务时，经常不是一次性从头跑到尾。 + +它会遇到很多小岔路： + +1. 发现两个实现方案，需要你选一个。 +2. 要运行一个有风险的命令，需要你批准。 +3. 测试失败了，需要你判断是继续修，还是换方向。 +4. 读完代码后发现需求不清楚，需要你补一句上下文。 +5. 完成修改后，需要你看 diff 和测试结果。 + +这些节点都很小，但会让整个任务停下来。 + +以前你必须坐在电脑前，才能继续推进。现在 Codex 移动端把这些节点搬到了手机上。 + +你在外面也能查看 Codex 当前做到了哪一步，看到它的发现，批准下一步，切换模型，补充新想法，或者直接改变方向。 + +这才是移动端真正有价值的地方。 + +它不是让你在手机上写代码，而是让你在手机上让代码任务不中断。 + +## 所有线程都能跟上 + +OpenAI 还强调了一点：这不只是给电脑派一个新任务，也不只是远程控制单个任务。 + +Codex 移动端能处理你已有的所有线程。 + +这点很关键。 + +Agent 工作经常不是一个任务，而是一组并行任务。一个线程在改 Bug，一个线程在写测试，一个线程在调研接口，一个线程在整理实现方案。 + +真正需要移动端支持的，不是“我突然想到一个任务，发给电脑”，而是“我已经有很多任务在跑，我要随时知道哪个需要我介入”。 + +所以 Codex 移动端更像一个随身任务控制台。 + +它让你不用一直守在电脑旁边，也不会因为离开电脑就失去对 Agent 工作的掌控。 + +## 安全设计也很重要 + +这类功能最容易被误解的地方是安全。 + +如果只是把本机服务暴露到公网，当然很危险。开发机里往往有代码仓库、环境变量、API Key、SSH 配置、平台账号和各种本地权限。 + +OpenAI 这次提到，Codex 使用安全中继层，让受信任的机器能在不同设备之间保持可访问，但不需要把机器直接暴露到公共互联网。 + +这个方向是对的。 + +Agent 的执行环境越强，里面的敏感信息就越多。移动端如果想参与工作流，最好的方式不是复制环境，而是安全地连接环境。 + +文件还在原来的机器上。 + +权限还在原来的机器上。 + +凭据还在原来的机器上。 + +手机只负责查看、审批和指挥。 + +这才符合真实开发环境的安全边界。 + +## Remote SSH 补上了企业场景 + +这次更新不只是在手机上加一个入口，OpenAI 还把 Remote SSH 正式推到了 generally available。 + +Codex 桌面应用现在可以识别 SSH 配置里的主机，并在远程机器里创建项目、运行线程。 + +这个能力对企业场景很关键。 + +很多团队本来就不在个人电脑上开发，而是在受管理的远程环境里工作。那里面有公司批准的依赖、凭据、安全策略和算力资源。 + +如果 Codex 只能跑在个人电脑上，它就很难进入这类工作流。 + +Remote SSH 的意义在于：Codex 可以进入企业已经认可的开发环境，而不是要求企业为了 Agent 重建一套新环境。 + +桌面端启动任务，远程环境执行任务，手机端监督任务。 + +这条链路一旦跑通，Codex 就不只是个人开发者工具，而更像团队基础设施的一部分。 + +## Hooks 和访问令牌让它更像生产工具 + +OpenAI 这次还发布了两个偏工程化的能力。 + +一个是 Programmatic access tokens。 + +Enterprise 和 Business 工作区可以从 ChatGPT workspace 设置里发放有作用域的凭据，用在 CI、发布流程和内部自动化里。 + +另一个是 Hooks。 + +Hooks 现在正式可用，并且覆盖所有计划。它可以用来扫描提示中的密钥、运行验证器、记录对话、创建记忆，或者按仓库和目录定制 Codex 行为。 + +这两个能力听上去没有移动端那么抓眼球，但其实更接近生产环境真正需要的东西。 + +Agent 不是只靠“会聊天”就能进生产的。 + +它要能接入流程，能被约束，能被审计，能在关键动作前后触发检查。 + +Hooks 解决的是可定制和可治理。 + +Programmatic access tokens 解决的是自动化系统怎么安全地调用 Codex。 + +移动端解决的是人怎么随时介入。 + +这三件事合起来，Codex 的形态就完整很多了。 + +## HIPAA 支持释放了一个信号 + +OpenAI 还提到，符合条件的 ChatGPT Enterprise 工作区，可以在 CLI、IDE、Codex app 这些本地环境里使用符合 HIPAA 要求的 Codex。 + +这个更新不一定和普通用户直接相关，但信号很明确：Codex 正在往更严肃的行业场景走。 + +医疗、金融、企业内部系统这些场景，不缺“能写代码的模型”。 + +它们缺的是能进入真实工作环境、尊重权限、满足合规要求、并且能被管理的 Agent。 + +所以 HIPAA 支持不是一个孤立功能。 + +它和 Remote SSH、Hooks、访问令牌、安全中继层，本质上都指向同一个方向：Codex 要从个人效率工具，变成可被组织采用的工程 Agent。 + +## 真正的变化是协作节奏 + +OpenAI 在文章里提到，现在每周已经有超过 400 万人在使用 Codex。 + +这个数字背后有一个更重要的变化：人和 Agent 的协作不再是短对话，而是长线程。 + +短对话里，人发一句，模型回一句。 + +长线程里，Agent 会自己读代码、改文件、跑测试、整理结果，然后在关键节点停下来问你。 + +所以未来的 AI 编程工具，移动端不应该只是一个聊天入口。 + +它应该是一个状态面板，一个审批入口，一个方向盘。 + +你不需要在手机上完成所有工作。 + +你只需要在关键时刻出现一下。 + +Codex 移动端的价值就在这里。 + +它让 Agent 工作不再被一台电脑、一张桌子、一个固定场景绑住。代码仍然在正确的环境里跑，人可以在任何地方接上工作流。 + +这才是 Agent 时代移动端该有的样子。 diff --git "a/ai-articles/01-agent-and-coding/Grok Build \350\242\253\344\274\227\344\272\272\345\224\276\351\252\202\357\274\214\347\273\223\346\236\234\350\200\201\351\251\254\346\212\212\345\256\203\345\274\200\346\272\220\344\272\206.md" "b/ai-articles/01-agent-and-coding/Grok Build \350\242\253\344\274\227\344\272\272\345\224\276\351\252\202\357\274\214\347\273\223\346\236\234\350\200\201\351\251\254\346\212\212\345\256\203\345\274\200\346\272\220\344\272\206.md" new file mode 100644 index 0000000..21c182b --- /dev/null +++ "b/ai-articles/01-agent-and-coding/Grok Build \350\242\253\344\274\227\344\272\272\345\224\276\351\252\202\357\274\214\347\273\223\346\236\234\350\200\201\351\251\254\346\212\212\345\256\203\345\274\200\346\272\220\344\272\206.md" @@ -0,0 +1,148 @@ +# Grok Build 被众人唾骂，结果老马把它开源了 + +[English](../../en/ai-articles/01-agent-and-coding/grok-build-was-criticized-then-open-sourced.md) | [中文](./Grok%20Build%20%E8%A2%AB%E4%BC%97%E4%BA%BA%E5%94%BE%E9%AA%82%EF%BC%8C%E7%BB%93%E6%9E%9C%E8%80%81%E9%A9%AC%E6%8A%8A%E5%AE%83%E5%BC%80%E6%BA%90%E4%BA%86.md) + +> 日期：2026-07-22 + +Grok Build 前两天属实是站在风口浪尖上了。 + +先给大家先复盘一下整个事情。 + +一份针对 `grok 0.2.93` 的[流量分析](https://gist.github.com/cereblab/dc9a40bc26120f4540e4e09b75ffb547)显示，Grok Build 在测试中上传了整个 Git 仓库，其中包括未被 Agent 读取的文件和 Git 历史；研究者还在上传内容里找到了测试用的 `.env` 字符串。 + +这份分析确实证明了数据传输、服务端接收和存储，但**没有证明 xAI 一定拿这些数据训练了模型**。 + +云端 AI 编程工具把任务需要的代码发给模型，这很正常。 + +争议点在于，它传出去的代码范围远超当前的任务需要，而且当时的安装和快速上手文档没有把整库上传机制讲明白。 + +这才是令大家闹心，唾骂的地方。 + +SpaceXAI 随后宣布把 Grok Build CLI 里的 `/privacy` 作为回应。这个命令用于查看或切换隐私与数据保留状态。 + +SpaceXAI 对 Grok Build 数据问题的回应 + +*图源：SpaceXAI 官方回应截图* + +当你在命令行敲入 `/privacy` 的时候，界面会明确标注代码不会被用于模型训练。 + +Grok Build CLI 的 privacy 状态 + +*图源：Grok Build CLI 截图* + +这里要给大家提个醒了：**不会用于训练，不等于数据完全不会离开本机。** + +云端模型想理解代码，总要接收一部分上下文。前面的流量分析也发现，在当时被测试的版本里，关闭 Improve the model 后，整库上传仍然会发生。 + +--- + +然后，在今天 7 月 15 日，SpaceXAI 宣布把 Grok Build 开源，同时重置所有用户的使用额度。 + +SpaceXAI 宣布开源 Grok Build + +*图源：SpaceXAI 官方账号截图* + +老马也正面回应了这个事情。 + +Elon Musk 对 Grok Build 隐私问题的回应 + +*图源：Elon Musk 公开回应截图* + +这次开源，看着像是让广大开源爱好者参与进来。从另一个角度看，它也明显带着危机回应和信任修复的色彩。 + +因为挨骂和公关修复的时间离得太近了。 + +默认保留关闭、历史数据删除、源码公开、额度重置，几个措施同时出现了。说这和前面的隐私争议完全没关系，我反正是不信的。 + +--- + +很多人看到 Grok Build 开源，很容易理解成 Grok 模型也开了。还是不一样的。 + +[官方仓库](https://github.com/xai-org/grok-build)开放的是 Grok Build 的 Rust CLI/TUI、Agent 运行时和工具框架，第一方代码采用 Apache 2.0 许可证。**Grok 4.5 的模型权重、训练代码和 xAI 云端服务没有随之开放。** + +![Grok Build GitHub 仓库与许可证](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260716082850739.png) + +*图源：Grok Build 主页* + +严格来说，这是真开源了。Apache 2.0 允许使用、修改、分发和做商业衍生。 + +而且它不只是把一个空壳扔出来。你可以从源码构建 CLI，查看文件读取、命令执行、沙箱、工具调用和上传相关实现。 + +官方文档还支持配置自定义模型和 `base_url`，所以你能把这个 Harness 接到其他 API，或者接到兼容接口的本地推理服务。 + +我看了一下 Grok Build 的开源仓库，官方已经写得很明确： + +![Grok Build 仓库贡献政策](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260716083124561.png) + +*图源：Grok Build GitHub 仓库截图* + +- 仓库目前只有一次历史提交； +- 官方明确表示不接受外部 Pull Request 和主动提交的安全补丁； +- GitHub 上还没有与源码仓库对应的正式 Release； +- 开源代码是否与用户下载的官方二进制逐字对应，还需要可复现构建、版本标签和签名机制来证明。 + +官方在 [CONTRIBUTING.md](https://github.com/xai-org/grok-build/blob/main/CONTRIBUTING.md) 里直接写的很明确。 + +![image-20260716095816563](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260716095816563.png) + +所以我理解 Grok 现在的路线是这样的：你可以看、可以本地编译、可以 Fork，也可以基于 Apache 2.0 做自己的版本； + +但是官方暂时不准备跟社区一起开发主仓库。 + +这也解释了为什么仓库没有开放常见的公共 Issue 和 PR 流程。 + +安全问题有单独的 `SECURITY.md` 通道，普通功能建议和代码贡献暂时进不了主仓库。 + +image-20260716100013245 + +说我得难听一点：代码给你看，Fork 也随你便，但官方暂时不想收你的 shit code 。。。 + +--- + +Grok Build 这次开源也不是先例，前面已经有 [Codex CLI](https://github.com/openai/codex) 和 [Gemini CLI](https://github.com/google-gemini/gemini-cli)。它们同样没有开放背后的模型权重，开放的都是 Agent CLI 和运行框架。 + +**Codex CLI：** + +![Codex CLI GitHub 仓库](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260716083543195.png) + +*图源：OpenAI Codex GitHub 仓库截图* + +**Gemini CLI：** + +Gemini CLI GitHub 仓库 + +*图源：Google Gemini CLI GitHub 仓库截图* + +区别主要在社区治理。 + +Codex 和 Gemini CLI 都保留了完整的公开提交历史，也开放 Issue、Pull Request 和讨论区。 + +Gemini CLI 的 README 甚至明确邀请社区提交代码改进。 + +也就是说，你该提 Issue 提 Issue，该提 PR 提 PR。 + +至于 A 社的 Claude Code，源码确实也被人扒出来了，我相信基本上大家也是人手一份了。 + +所以这次 Grok build 确实开源了，但目前来看，他们并不想做社区。 + +不过我看到某知名社交平台上几乎全是吹的，鲜有人提到官方不接受公共 PR 这件事。这是我看到少数直接点出问题的评论。 + +关于 Grok Build 不接受外部贡献的评论 + +*图源：社交平台公开评论截图* + +--- + +如果你用 Cursor，这几天确实是甜蜜时刻了。 + +Cursor 直接把模型使用量翻倍了。Grok Build 这边随后选择直接重置用户额度。 + +Cursor 提供 Grok 4.5 双倍用量 + +老马这一套操作确实听起来很诱人，又是把源码开放，又是重置额度的，而且 Cursor 这边直接把额度 double 了。 + +所以我更加确切地相信，这次开源确实是一场公关上的胜利。它迅速的转移了公众的注意力。 + +所以这次开源最大的价值，我认为其实是把一部分信任从公司承诺变成了可检查的源码。 + +但它既不能抹掉此前已经抓到的上传行为，也不能单独证明当前官方二进制已经彻底停止整库上传了。 diff --git "a/ai-articles/01-agent-and-coding/Loop \350\277\230\346\262\241\347\216\251\346\230\216\347\231\275\357\274\214Graph Engineering \345\217\210\347\201\253\344\272\206\357\274\232\350\257\264\347\231\275\344\272\206\357\274\214\345\260\261\346\230\257\347\273\231 Agent \347\273\204\344\270\252\345\233\242\351\230\237.md" "b/ai-articles/01-agent-and-coding/Loop \350\277\230\346\262\241\347\216\251\346\230\216\347\231\275\357\274\214Graph Engineering \345\217\210\347\201\253\344\272\206\357\274\232\350\257\264\347\231\275\344\272\206\357\274\214\345\260\261\346\230\257\347\273\231 Agent \347\273\204\344\270\252\345\233\242\351\230\237.md" new file mode 100644 index 0000000..c0eb68c --- /dev/null +++ "b/ai-articles/01-agent-and-coding/Loop \350\277\230\346\262\241\347\216\251\346\230\216\347\231\275\357\274\214Graph Engineering \345\217\210\347\201\253\344\272\206\357\274\232\350\257\264\347\231\275\344\272\206\357\274\214\345\260\261\346\230\257\347\273\231 Agent \347\273\204\344\270\252\345\233\242\351\230\237.md" @@ -0,0 +1,231 @@ +# Loop 还没玩明白，Graph Engineering 又火了：说白了，就是给 Agent 组个团队 + +[English](../../en/ai-articles/01-agent-and-coding/graph-engineering-is-already-taking-off.md) | [中文](./Loop%20%E8%BF%98%E6%B2%A1%E7%8E%A9%E6%98%8E%E7%99%BD%EF%BC%8CGraph%20Engineering%20%E5%8F%88%E7%81%AB%E4%BA%86%EF%BC%9A%E8%AF%B4%E7%99%BD%E4%BA%86%EF%BC%8C%E5%B0%B1%E6%98%AF%E7%BB%99%20Agent%20%E7%BB%84%E4%B8%AA%E5%9B%A2%E9%98%9F.md) + +> 日期：2026-07-21 + +7 月 18 日，OpenClaw 作者 Peter Steinberger 在 X 上问了一句：大家还在聊 Loop，还是已经转向 Graph 了？ + +Peter Steinberger 讨论 Loop 和 Graph + +两天后，Codez 写了一篇很长的教程，给出一条从零开始学习 Graph Engineering 的 14 步路线。 + +我相信很多人的反应跟我一样：**Loop 还没玩明白，怎么又开始画图了？** + +先补一句 Loop 是啥：Loop 是让单个 Agent 反复自我检查、自我修正，直到结果达标为止的机制——写完一遍、检查一遍，不行就重来，做到合格为止。下文会反复拿它当对照。 + +Graph Engineering 14 步路线图 + +*图源：[Codez 原文](https://x.com/0xCodez/status/2079165300625330317)* + +所以这篇我不按 14 个名词逐一讲——那 14 步里出现的 Node、Edge、Schema、Router、Fan-out/Fan-in，后面都会用大白话覆盖到。我换成一个普通人能听懂的说法： + +**Graph Engineering，就是给一群 Agent 分工，规定工作怎么交接、哪里检查、什么时候停。** + +先记住这句话，后面的图就没那么吓人了。 + +## 先把 Agent 想成一个新员工 + +假设你招了一个新员工，让他每天给你写一份 AI 新闻简报。 + +最简单的做法，是把所有事都交给他：找新闻、读原文、核对真假、挑重点、写文章、改错字。 + +这就是大家熟悉的单 Agent。 + +Prompt 相当于你给他的工作要求。Loop 相当于他写完检查，发现不对再重做，一直做到合格为止。 + +简单任务做起来没问题，但事情一多，这位员工就开始忙不过来了。他需要一边翻资料，一边记数字，还要考虑文章结构，能记住的上下文越来越满，前面看过的东西也忘得越来越快。 + +Graph Engineering 做了一件大家看上去应该都知道如何优化的事儿：**别让一个人干这么多事儿了，组个团队。** + +有人找资料，有人核对事实，有人写稿，还有人负责挑错。分工明确，最终促成一篇成稿落地。 + +![Graph、Agent 和 Graph Reasoning 的关系](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/8a82f52a5dd286c95e78afbf67cbf0f4beab8ba8.jpg) + +顺带澄清一个容易混淆的词：图里出现的 Graph Reasoning，和本文讲的 Graph Engineering 不是一回事。Graph Reasoning 偏向模型内部的推理结构，Graph Engineering 偏向工程层面的多 Agent 编排。这篇文章讲的是后者。 + +这张图看起来很复杂。其实下面那些小圆点、小方框，大多都可以理解成不同员工和不同工作。 + +## Node 是员工，Edge 是交接单 + +Graph 里最重要的两个词是 Node 和 Edge。 + +Node，也就是节点。你可以把它理解成一个岗位：资料员、翻译、事实核对员、作者、审稿人。 + +Edge，也就是边缘。它表示工作从谁手里交到谁手里，以及交过去什么东西。 + +![节点负责工作，边只传递真实依赖的数据](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/a6eec3093e796d8f059b87e4ec71fa85d64937d1.png) + +这里有个特别容易踩的坑：做事有先后顺序，但不代表它们存在依赖关系。 + +比如我让 Agent 总结这份文件，然后查一下北京天气。天气查询根本不需要等待总结结束后方可执行，而是两个任务可以同时开始。 + +很多 Agent 慢就慢在这里。所有工作被写成 A → B → C → D，前一个任务结束不了，后一个任务绝不开始。 + +![线性链条剪掉假依赖后，变成可并行的图](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/f90dee9452cfa1118adf957a767b515fca2e713a.png) + +再举个更直观的例子：B 和 C 都只需要 A 提供的资料，C 并不需要 B 的结果。那么 A 完成后，就可以同时启动 B 和 C，没必要让 C 排在 B 后面干等。 + +所以，Graph Engineering 最基础的能力，是看清任务之间真正的依赖关系：**哪些任务需要等待，哪些任务可以同时开工。** + +--- + +任务可以并行以后，问题就从谁等谁，变成了结果怎么交给下一个 Agent。 + +比如，资料员 Agent 查完资料，只交回来一大段文字。负责写作的 Agent 既找不到原文链接，也分不清哪些是事实、哪些是结论，只能自己再猜一遍。 + +解决方法，是给每次交接规定一个固定格式。比如资料员必须返回三项内容：标题、原文链接、重要程度。少一项，这次交接就不合格；全部齐全之后，写作 Agent 才继续工作。 + +技术上，这份格式规则叫作 `Schema`。你可以把它理解成一张统一的交接单。 + +![节点契约把 Provider、Consumer、Schema 和测试连接起来](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/86d287ae73aaa5fb075020884ff9f13b0d2dc514.jpg) + +现在再看 Node 和 Edge 就容易理解了：Node 规定这个 Agent 负责什么，Edge 规定它要把哪些数据交给谁。交接格式越清楚，下一个 Agent 就越容易理解。 + +![复杂任务图中的数据依赖与执行关系](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/2bd1e378505609963837e40d568b80c650afb2d2.png) + +所以，多 Agent 真正难的是提前写清楚每一步的交付物、如何检查、出错后怎么办。 + +如果这些规则没定好，那么 Agent 数量越多，造成的返工反而越多。 + +## 最常用的图，其实就是一颗菱形 + +最常见的 Graph 形状并不复杂。 + +先把任务拆分，让几个人同时做；做完之后再把结果收回来，去重、筛选；最后交给一个人统一出结果。 + +![Subagents 与 Agent Teams 的并行方式](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/7b0fa1e3c97561416e2a402fff6252e642e6f77c.jpg) + +就拿写这篇文章来举例子。 + +一个 Agent 读 X 原文，一个 Agent 查 Anthropic 官方文档，另一个 Agent 看最近大家怎么讨论 Graph Engineering。三边可以同时开始。 + +资料回来后，先去掉重复内容，再交给最终的拟稿人和审核人（也就是我）。所以我不用背着十几个网页工作，我只需要拿到整理好的结果就行了。 + +![多路结果在屏障节点汇合](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/a3655de836c7163522d45979d99edd90f54dff02.jpg) + +这就是 Fan-out 和 Fan-in。 + +Fan-out 是把工作分出去，Fan-in 是把结果收回来。两个动作连在一起，就构成了下面这颗菱形形态。 + +![Graph Engineering 最常用的菱形拓扑](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/4442b333b5e3a584d42a02f0b04e2d92d710bafe.png) + +放到写文章这件事里就很好理解了：先让几个 Agent 同时查资料，再让程序自动去重、分类，最后把整理好的材料交给一个 Agent，由它形成最终结论。 + +--- + +前面几个 Agent 已经同时找完资料，程序也完成了去重和分类。但这些材料还不能直接拿来写文章，因为它们可能引用了过期消息，也可能把别人的转述当成官方结论。 + +所以，最后一个 Agent 拿到材料后，需要先做一轮验收判断：链接能不能打开，数字和日期能不能对上，不同来源有没有互相矛盾，判断之后才能开始写。 + +技术上，这个负责挑错的角色叫 `Reviewer` 或 `Verifier`。它的工作不是再写一份答案，而是检查前面的答案能不能相信。 + +但"检查"这件事并不是一个固定的动作，力度也得看事情轻重。 + +一个普通的观点，让一个 Agent 快速核对就够了；涉及重要数据、安全问题或产品结论时，就要安排几个 Agent 从不同角度交叉检查。决定"这件事该走哪条检查流程"的角色，叫 `Router`。它像一个分诊台，根据重要程度把任务引向不同的边。 + +![路由节点根据风险等级选择不同的边](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/48776aaaf80ca399917b38999a78631963fba116.png) + +如果负责查资料的 Agent 说官方已经确认，验证 Agent 就要找到官方原文；如果只能找到媒体转述，这条结论就要降级，甚至退回去重新查。只有经得住检查的内容，才会进入到文章中。 + +![多个验证器从不同角度检查同一个发现](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/434577f632d762b0dd1db2b8701a4cee06295fb5.png) + +如果 Agent 执行的不是查资料，而是修改代码，还要多做一步隔离：给每个 Agent 一份独立的工作区。否则两个人同时改同一个文件，后面保存的人可能直接盖掉前一个人的成果。 + +![用 Git worktree 隔离多个并行写入节点](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/60d9fd2c93126b48e0775f9f7482341d1c7c1875.png) + +如果检查发现问题后，需要退回前面的 Agent 补资料的阶段，然后再检查一次。这样就形成了一个循环。 + +![循环必须带反馈、验证与停止条件](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/a77a58dd40d7b13a90d8298db1d6e352aea317bd.png) + +但是循环必须规定什么时候结束。比如连续两轮没有发现新问题就停止，否则就像老板一直喊再查一遍，Agent 会不停工作，token 也会一直烧。 + +整套流程说白了就是：**有人找资料，有人整理资料，还有人专门检查资料。检查不通过就退回重做，通过之后才下最终结论。** + +--- + +前面一直在说把任务分给多个 Agent，但有件事不能忽略：每启动一个 Agent，它都要单独读取材料、思考并输出答案，这些操作都会消耗 token。 + +比如为了写一篇文章，同时叫来十个最强模型查资料，确实可能比一个模型查得更全面，但也相当于花了十倍价钱请了十位专家。并行能节省等待时间，却不会让这十个人免费工作。 + +省钱的办法，是别让所有工作都交给最贵的模型。提取标题、整理格式、简单分类，可以让便宜的模型完成；判断消息真假、处理冲突、形成最终结论，再交给能力更强的模型。 + +这就像一个编辑部：整理资料不必总编辑亲自上，真正需要拍板时再找他。 + +![Claude Code 中为不同节点选择不同模型](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/82e60695a9a9ecec281a5da1ff9ea87ee008e00f.jpg) + +除了选什么模型，任务怎么排也会影响速度。 + +比如十份资料要放在一起去重，那就必须等十个 Agent 全部回来后再开始，像开会一样，人到齐了才能进入下一步。 + +但如果每份资料可以单独处理，就不用等所有人。第一份回来就先检查第一份，第二份回来再处理第二份，像流水线一样。 + +![parallel 屏障与 pipeline 流水线的延迟差异](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/e86b0f2b8908c35bd265cadc64eace783febc602.png) + +所以，设计一张 Agent Graph，本质上还要算清三笔账：启动多少个 Agent、每个 Agent 使用什么模型、哪些步骤必须互相等待。 + +**Graph 设计得好，是用更少的钱更快地完成任务；设计得不好，只是让更多模型一起更快地烧 token。** + +--- + +讲到这里，你可能已经发现了一个问题：Graph 确实能让多个 Agent 一起工作，但这张图本身还是要有人设计。 + +谁去查资料，谁负责验证，哪些任务可以同时开始，哪一步必须等待，最后由谁下结论——以前，这些规则通常要开发者提前写好。 + +Claude Code 的 Dynamic Workflows 想做的，就是把这部分工作也交给 Claude。 + +关于 [Claude Dynamic Workflows](https://mp.weixin.qq.com/s/0tbHJ3uH-WXZHlTuZcEX_A) ，你可以阅读这篇文章。 + +你只需要告诉它最终目标。Claude 会先分析任务，再生成一段 JavaScript 编排脚本。 + +还是以写文章为例，它可以安排几个 Agent 分头查找原文、官方文档和外部讨论；等资料回来后，让程序去重；再叫验证 Agent 检查来源，最后交给写作 Agent 输出文章。 + +![Claude Code 通过 ultracode 动态生成 Workflow](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/293e57b52461b68cb2f98f551fcb7497defc3930.jpg) + +在 Claude Code 里，你可以直接要求它使用 Workflow，也可以运行 `/deep-research`。打开 `ultracode` 后，Claude 还会先判断当前任务够不够复杂，是否真的值得启动一组 Agent。 + +Claude Dynamic Workflows 运行界面 + +*图源：[Anthropic Dynamic Workflows 官方介绍](https://claude.com/blog/introducing-dynamic-workflows-in-claude-code)* + +这里有个很容易误解的说法：编排脚本可以做到零模型 token。 + +它真正的意思是，分发任务、等待结果和合并数据这些管理动作由普通 JavaScript 完成，不需要再调用一次模型。但真正出去干活的每个 Agent，仍然会正常消耗 token。 + +说白了，**排班表不拿工资，不代表排班表里的员工也不用拿工资。** + +截至 2026 年 7 月，Claude 官方文档给出的上限是同时运行 16 个 Agent，单次 Workflow 最多启动 1,000 个 Agent（见 [Claude Code Docs](https://code.claude.com/docs/en/workflows)）。这代表系统能承载多大的任务，并不代表普通任务也应该把人数拉满。 + +下面这张图，就是原文最后组装出来的一套完整流程。 + +![一张完整的 Agent Graph：展开、归并、验证与综合](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/fd57f0339b3364eceebcf8fe5242dbef00753ce8.png) + +第一眼看上去密密麻麻，拆开后仍然是前面讲过的几件事：先确定任务范围，再分头查资料；用固定格式交接，用程序整理；安排 Agent 验证，最后形成结论；整个过程还要控制停止条件和成本。 + +Claude 现在可以自动生成这套流程，但仍然要检查三个问题：任务拆得是否合理，该验证的地方有没有验证，启动这么多 Agent 是否值得。也就是说，我们不一定要亲手画出每个节点，但仍然要判断 Claude 安排的这套分工能不能真正完成任务。 + +--- + +看到这里，小白不需要马上安装一个 Graph 框架，更不用给每个任务都安排十几个 Agent。 + +如果只是总结一份 PDF、修改一个标题，交给一个 Agent 从头做到尾，通常更快也更便宜。为了显得高级硬拆成一张图，只会增加等待、交接和出错的机会。 + +当任务开始出现下面这些情况时，Graph 才真正有用：有几块工作可以同时进行；一个 Agent 已经看不过来；结果必须经过独立检查；整个过程会反复执行很多次。 + +真要动手，也可以从最简单的一步开始。先让一个 Agent 完成整个任务，找到最慢或者最容易出错的环节；再拆出一个可以并行的分支；确实担心答案不可靠时，再加一个验证 Agent。等流程稳定之后，最后才考虑框架和自动编排。 + +说到底，**Loop 解决的是一个 Agent 如何反复工作，直到把事情做完；Graph 解决的是多个 Agent 如何分工、交接、检查，以及如何避免把 token 白白烧掉。** + +Graph 不是重点，Graph 里每一条箭头为什么存在，才是 Graph Engineering 真正要解决的问题。 + +--- + +### 参考资料 + +- [Codez：Graph Engineering with Claude，14 步原文](https://x.com/0xCodez/status/2079165300625330317) + +- [Anthropic：Introducing dynamic workflows in Claude Code](https://claude.com/blog/introducing-dynamic-workflows-in-claude-code) + +- [Claude Code Docs：Dynamic Workflows](https://code.claude.com/docs/en/workflows) + +- [LangGraph 官方文档：Graph API overview](https://docs.langchain.com/oss/python/langgraph/graph-api) diff --git "a/ai-articles/01-agent-and-coding/Node.js 22 ESM \345\212\240\350\275\275 bug \345\257\274\350\207\264 OpenClaw \346\234\215\345\212\241\345\256\225\346\234\272\345\205\250\347\250\213\345\244\215\347\233\230.md" "b/ai-articles/01-agent-and-coding/Node.js 22 ESM \345\212\240\350\275\275 bug \345\257\274\350\207\264 OpenClaw \346\234\215\345\212\241\345\256\225\346\234\272\345\205\250\347\250\213\345\244\215\347\233\230.md" new file mode 100644 index 0000000..b46f0bc --- /dev/null +++ "b/ai-articles/01-agent-and-coding/Node.js 22 ESM \345\212\240\350\275\275 bug \345\257\274\350\207\264 OpenClaw \346\234\215\345\212\241\345\256\225\346\234\272\345\205\250\347\250\213\345\244\215\347\233\230.md" @@ -0,0 +1,525 @@ +> 日期：2026-03-31 + +## Node.js 22 ESM 加载 bug 导致 OpenClaw 服务宕机全程复盘 + +[toc] + + + +事情是这样的，我不是说我之前把 OpenClaw 接入了我个人的微信公众号吗，文章一经发布后有很多 + + + +可以查看这篇文章 + + + +然后就在昨天下午，我的 Clawra 突然崩了，直接服务不可用了，直接给这哥们整懵了我估计。 + + + +image-20260327221151372 + + + +接下来我会用详细的 + +--- + + + +服务挂了，我赶紧登上服务器一看：`ps aux | grep node` + + + +输出： root 555293 0.1 2.0 11816600 83864 ? Ssl Mar25 3:59 node /root/wechat-bridge/index.js + + + +好消息：wechat-bridge（这是我写的一个微信桥接的 node 服务，用于连接微信公众号和远端服务器） 还跑着呢，在 5000 端口正常监听，能接收到微信的请求。 坏消息：找不到 OpenClaw 进程。 + + + +**第一步：确认 OpenClaw 确实没起来** + + + +OpenClaw 我用 systemd 管着，看看状态： `systemctl --user status openclaw-gateway` + + + +输出： openclaw-gateway.service - OpenClaw Gateway (v2026.3.13) + Loaded: loaded (/root/.config/systemd/user/openclaw-gateway.service; enabled; vendor preset: enabled) + Active: activating (auto-restart) (Result: exit-code) since Fri 2026-03-27 17:26:05 CST; 1s ago + Process: 776260 ExecStart=/usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789 (code=exited, status=1/FAILURE) + Main PID: 776260 (code=exited, status=1/FAILURE) + + + +果然，进程一起就退出，exit code 1。systemd 一直在自动重启，但一起就崩。 + + + +为啥啊，找找日志吧。 + + + +`journalctl --user -u openclaw-gateway.service -n 50 --no-pager` + + + +输出： No journal files were found. + + + +-- No entries -- + + + +哦对，user systemd 日志可能没配置，去看 OpenClaw 自己写的文件日志： + + + +`tail -50 /tmp/openclaw/openclaw-$(date +%Y-%m-%d).log` + + + +这次有内容了，但是...日志只打印到启动加载插件那就断了： + + + +{"0":"{\"subsystem\":\"plugins\"}","1":"[plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: + openclaw-weixin (/root/.openclaw/extensions/openclaw-weixin/index.ts). Set plugins.allow to explicit trusted + ids.","_meta":...} + {"0":"gateway/channels/openclaw-weixin","1":"[runtime] setWeixinRuntime called, runtime set successfully","_meta":...} + + + +然后...就没了。没有错误，没有异常，直接没了。这就奇怪了，为什么启动到一半没了？让我直接前台跑起来看看： + + + +```shell +cd /root + +node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789 + +file:///usr/lib/node_modules/openclaw/dist/reply-Bm8VrLQh.js:162924 +export { resolveCommandSecretRefsViaGateway as $, formatSlackStreamModeMigrationMessage as $_, +markGatewaySigusr1RestartHandled as $a, ... + ... + ... (几千行重复) +RangeError: Maximum call stack size exceeded + at compileSourceTextModule (node:internal/modules/esm/utils:346:16) + at ModuleLoader.moduleStrategy (node:internal/modules/esm/translators:107:18) + at #translate (node:internal/modules/esm/loader:546:20) + at afterLoad (node:internal/modules/esm/loader:596:29) + at ModuleLoader.loadAndTranslate (node:internal/modules/esm/loader:601:12) + at #createModuleJob (node:internal/modules/esm/loader:624:36) + at #getJobFromResolveResult (node:internal/modules/esm/loader:343:41) + at ModuleLoader.getModuleJobForImport (node:internal/modules/esm/loader:311:41) +``` + + + +看到这里我就明白了——调用栈溢出了，而且是溢出在 Node.js 自己的 ESM 模块加载器里面，不是 OpenClaw 业务代码错了。 + + + +第一次猜想：栈分配小了，调大不就行了？ + + + +看到 Maximum call stack size exceeded，第一反应肯定是——默认栈大小不够啊，给它调大不就完了？ + + + +Node js 启动参数有 --stack-size 可以指定栈大小（单位 KB），默认好像是 984 还是几千，我给它翻几倍： + + + +编辑 systemd 服务文件：`vim ~/.config/systemd/user/openclaw-gateway.service` + + + +改成： + + + +ExecStart=/usr/bin/node --stack-size=32768 /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789 + + + +32768 KB 就是 32MB，默认才不到 1MB，这下总够了吧？ + + + +reload 重启： + + + +```shell +systemctl --user daemon-reload +systemctl --user restart openclaw-gateway.service +``` + + + +等 10 秒看状态： + + + +`systemctl --user status openclaw-gateway.service --no-pager` + + + +还是一样：code=exited, status=1/FAILURE，一起就崩。那我给你加到 64 MB。 + + + +ExecStart=/usr/bin/node --stack-size=65536 /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789 + + + +再试一次，还是不行。 咬咬牙，直接给到 128MB： + + + +ExecStart=/usr/bin/node --stack-size=131072 /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789 + + + +还是失败。 + + + +这时候我意识到不对劲——这不是栈大小不够的问题，这是真·无限递归，你栈再大，它递归深度无限，总有爆的时候。 + + + +第二次猜想：安装包损坏了，重装 OpenClaw 试试？ + + + +会不会是我安装的时候网络断了，包没下全？或者缓存坏了？反正重装一下也不麻烦： + + + +`npm install -g openclaw --force` + + + +等待安装完成...然后再启动： + + + +`systemctl --user restart openclaw-gateway.service` + + + +这次我多等一会儿，15 秒后看状态： + + + +`systemctl --user status openclaw-gateway.service --no-pager` + + + +然后就。。。。。。 + + + +openclaw-gateway.service - OpenClaw Gateway (v2026.3.13) + Loaded: loaded (/root/.config/systemd/user/openclaw-gateway.service; enabled; vendor preset: enabled) + Active: active (running) since Fri 2026-03-27 19:26:04 CST; 21s ago + Main PID: 787646 (openclaw-gatewa) + Tasks: 11 (limit: 4559) + Memory: 455.3M + CPU: 8.836s + + Active: active (running)！起来了！ + + + +赶紧看看端口监听没： ss -tlnp | grep 18789 + + + +![image-20260327223349949](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260327223349949.png) + + + +```shell +curl -s --connect-timeout 5 http://localhost:18789/v1/chat/completions \ + -H "Authorization: Bearer b981b9c0226c262ad740c20506fdb81db913c73e356ead14" \ + -H "Content-Type: application/json" \ + -X POST -d '{"model":"openclaw:main","messages":[{"role":"user","content":"hello"}]}' + +响应回来了： + +{ + "id":"chatcmpl_8f902dd8-885a-48df-beb4-517e3fdbee28", + "object":"chat.completion", + "created":1774610855, + "model":"openclaw:main", + "choices":[{ + "index":0, + "message":{ + "role":"assistant", + "content":"你好呀！👋 我是 Clawra，有什么我可以帮你的吗？💃" + }, + "finish_reason":"stop" + }], + "usage":{ + "prompt_tokens":0, + "completion_tokens":0, + "total_tokens":0 + } +} +``` + + + +**完美，果然重装能解决 99.99% 的问题**。 + + + +## 为什么会出这个问题？深度分析 + + + +现在服务起来了，我们得复盘一下——到底为什么会出这个问题？真的是 Node.js 的 bug 吗？还是 OpenClaw 打包错了？ + + + +问题发生在哪个阶段？ + + + +从错误栈看： + + + +```js +RangeError: Maximum call stack size exceeded + at compileSourceTextModule (node:internal/modules/esm/utils:346:16) + at ModuleLoader.moduleStrategy (node:internal/modules/esm/translators:107:18) + at #translate (node:internal/modules/esm/loader:546:20) + at afterLoad (node:internal/modules/esm/loader:596:29) + at ModuleLoader.loadAndTranslate (node:internal/modules/esm/loader:601:12) + at #createModuleJob (node:internal/modules/esm/loader:624:36) + at #getJobFromResolveResult (node:internal/modules/esm/loader:343:41) + at ModuleLoader.getModuleJobForImport (node:internal/modules/esm/loader:311:41) +``` + + + +看到了吗？所有调用栈都在 Node.js 自己的 ESM 模块加载代码里面，没有一行是 OpenClaw 业务代码。说明进入无限递归的时候，OpenClaw 代码一行都没执行呢，加载阶段就炸了。 + + + +**为什么会无限递归？** + + + +现在的 npm 包分发 CLI 工具，有一种很常见的打包方式：把整个应用 + 所有依赖，打包成一个巨大的单文件 ESM，然后直接发布。 + + + +这样的好处是 + + - 用户安装就是一个文件，省得 node_modules 下一堆东西 + - 可以直接 node your-cli.js 就跑，不用找依赖 + - 适合全局安装的 CLI 工具 + + + +但这种打包方式有一个特点：所有模块都在一个文件里，打包工具会生成很多循环的 re-export——A 导出 B，B 导出 A，或者 index 导出所有子模块，子模块又 re-export 回 index。 + + + +在 Node.js 20 上面，这套逻辑跑的好好的，没问题。为什么 Node.js 22 就出问题了？ + + + +肯定是 Node.js 22 修改了 ESM 模块加载的实现。我去查了一下 changelog，Node.js 22 在 ESM 加载、模块解析这块确实做了不少改动。 + + + +大概率是： + + + + - 新的实现对"单文件多模块 + 循环 re-export"这种场景处理不好 + - 每次遇到 import 都重新走一遍完整解析流程 + - 然后就形成了递归调用——A 引用 B 触发解析 B，B 引用 A 又触发解析 A，这样无限循环下去 + + + +**** + + + +**为什么重装之后 1MB 就能跑了？** + + + +我在重装了 OpenClaw 之后，发现 即使默认 1MB 栈也能跑起来！一开始失败估计是旧安装包损坏了。 + + + +重装拿到了最新的打包输出，可能打包工具在新版本里对循环依赖处理更好了，递归深度刚好降到 1MB 能容纳。加上禁掉自重启避免了二次加载，就成了。 + + + +如果你也碰到这个问题，按这个来： + + + +### 方案一：直接绕过（推荐，我现在在用） + + + +修改你的 systemd 服务文件： + + + +```shell +# 只要不是特别极端，1MB 足够了 +ExecStart=/usr/bin/node --stack-size=1024 /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789 +# 加这个环境变量禁掉自重启，避免二次加载浪费栈 +Environment=OPENCLAW_NO_RESPAWN=1 +``` + + + +然后重启： + + + +```shell +systemctl --user daemon-reload +systemctl --user restart openclaw-gateway +``` + + + +验证： + + + +```shell +curl -s http://localhost:18789/v1/chat/completions \ + -H "Authorization: Bearer " \ + -H "Content-Type: application/json" \ + -d '{"model":"openclaw:main","messages":[{"role":"user","content":"hello"}]}' +``` + + + +能收到 AI 回复就成功了。 + + + +### 方案二：彻底解决——降级 Node 20 + + + +如果你碰着更大的包，1MB 还是爆，那就切回 Node 20： + + + +```shell +# 用 nvm 管理版本非常方便 +nvm install 20 +nvm alias default 20 +npm install -g openclaw --force +systemctl --user restart openclaw-gateway +``` + + + +## 复盘一下 + + + +这次排坑给我不少启发： + + + + 1. 大版本升级一定要谨慎——Node.js 这种底层工具，新项目你升没问题，生产环境跑的服务，大版本升级别急，等几个版本踩完坑再升不迟 + + + + 2. 错误栈会说实话——这次错误直接指到 Node 内部 ESM 加载器，一开始就没瞎猜 OpenClaw 代码错了，节省大量时间 + + + + 3. 从小到大试一遍——从最小栈开始试，你会发现其实没你想的那么糟糕，1MB 其实就够了 + + + + 4. 自重启有时候会添乱——OpenClaw 自带自重启，配合 systemd 其实没必要，禁掉反而解决问题 + + + + 5. Node 22 这个坑得记下来——碰到莫名其妙的栈溢出，先想想是不是撞这个 bug 了。 + + + +## 是不是误判 + + + +我一直在怀疑是不是误判了，因为这种递归导致的内存泄漏问题听起来太底层、太严重，如果真是 Node.js 的 bug，应该早就被发现了才对。 + + + +然后我就网上搜了一下，发现 Node.js 官方仓库已有完全相同的问题。 + + + +链接：https://github.com/nodejs/node/issues/52864 + +提交时间：2024年5月 + +状态：已被官方确认并处理 + + + +即**Node.js 22 的 ESM 模块加载器，在处理「循环引用 / 循环导出」时，会触发无限递归，最终导致栈溢出崩溃。** + + + +这个 bug 已经被官方进行修复。 + + + +而我出现的这个 bug 和上面还不一样。 + + + +这个 Bug 专门触发在： + + + +**大型单文件 ESM + 大量循环 re-export** + + + +也就是 webpack/rollup 打包的 CLI 工具。 + + + +截至目前（2026-03），**官方仍未修复**。 + + + +我已经把 issue 提交给 Node.js 官方了，issue 在这，https://github.com/nodejs/node/issues/62457 等着官方确认吧。 + + + +如果有新的消息我会给大家及时补充。 + + + diff --git "a/ai-articles/01-agent-and-coding/OpenClaw \345\207\211\344\272\206\357\274\214Hermes \345\267\262\350\207\263.md" "b/ai-articles/01-agent-and-coding/OpenClaw \345\207\211\344\272\206\357\274\214Hermes \345\267\262\350\207\263.md" new file mode 100644 index 0000000..392e8c0 --- /dev/null +++ "b/ai-articles/01-agent-and-coding/OpenClaw \345\207\211\344\272\206\357\274\214Hermes \345\267\262\350\207\263.md" @@ -0,0 +1,378 @@ +# OpenClaw 凉了，Hermes 当立 + +> 日期：2026-04-09 + +## 写在前面 + +大家还记得 2、3 月份 OpenClaw 的盛世么？ + +那时候技术圈几乎人手一个，GitHub star 数量一路狂飙，媒体争相报道，自媒体疯狂刷屏。所有人都在说：开源 AI Agent 的时代来了，OpenClaw 就是那个标杆。 + +然后—— + +3 月 31 号之后，我在 TG 上用 OpenClaw 的次数基本归零了。 + +image-20260409050232135 + +这不是我一个人的感受。Twitter 上的风向、社区的讨论热度、GitHub 的 issue 数量——都在说明同一件事：OpenClaw 的增长曲线，开始 flat（平）了。 + +image-20260409085112401 + +这篇文章主要聊三件事情：**OpenClaw 为什么不行了，Hermes Agent 是什么，以及这场 AI Agent 的新战局会怎么走。** + +废话不多说，先给大家把链接甩出来： + +https://hermes-agent.nousresearch.com/docs/getting-started/quickstart/ + +--- + +## OpenClaw 为什么从神坛跌落？ + +首先要提到一点的是，OpenClaw 不是烂，它本质上是一个**控制平面优先**的优秀框架。 + +它可以直连操作系统——读写文件、控制浏览器、操作 Shell。可以接入各种 LLM ，也可以配合 Ollama 使用，数据从头到尾不出你的机器。Skill 插件系统靠人工编写，采用文件驱动的身份系统 Soul.md 。这套设计对程序员非常友好，一切皆文件的思路让调试和审计都很直观。 + +那它为什么不行了？ + +**版本迭代引入了稳定性问题。** 这是我在各个社区和群里听到提到最多的原因。3 月前后的几个大版本在功能上做了不少改动，但也顺手带入了新的 bug。用户量大了之后，各种边缘场景暴露出来，issue 堆得越来越多，响应速度跟不上。 + +**技术债的雪球越滚越大。** OpenClaw 的架构设计追求成年人啥都要——既要控制文件系统，又要管浏览器，又要支持 Skill 插件系统，还要保证安全沙盒——这些目标之间本身就有张力。在没有足够多资源维护的情况下，顾此失彼就成了常态。 + +**更深层的原因：OpenClaw 的设计哲学是「人必须在决策环里」。** 这在早期是优势，是卖点。但当用户量大了之后，大多数普通用户并不想在每一步操作前都停下来确认。他们想要的是：说一声，事情办了。OpenClaw 给不了这个。 + +**最后是竞品的冲击。** Hermes Agent 这类新选手在开箱即用和智能进化上打了差异化的牌，把 OpenClaw 的目标用户分流了一部分。 + +--- + +## Hermes Agent 是什么？ + +Hermes Agent 是一个开源、自托管的持久型 AI Agent。 + +它和 OpenClaw 一样：开源、自托管、能接入 Telegram / Discord / Slack / WhatsApp 等聊天软件执行实际任务、数据不离你的机器。但两者的设计哲学，在根子上就不一样。 + +image-20260409050524628 + +**OpenClaw 的核心逻辑是：Agent = 你给工具 + 你给 Skill + 你全程盯着。** + +**Hermes 的核心逻辑是：Agent = 你给目标 + 它自己学 + 用久了比你自己还懂你。** + +这个差异听起来有点虚，举个例子你就明白了。 + +你用 OpenClaw 跑一个任务：你要告诉它用什么 Skill、文件放哪、Shell 怎么跑。下次做同类任务，这些你还得再说一遍。它是工具，很好用，但不会「长记性」。 + +image-20260409085248718 + +你用 Hermes 跑同一个任务：你只要说目标，它自己决定用什么方法。任务完成后，它会**把这次成功的执行路径提炼成一个 Skill**，存进技能库里。下次做同类任务，你不用说，它自己调用。而且如果你用新方法把效果做得更好，它会自动更新那个 Skill——旧的不如新的，存新的。 + +这就是 Hermes 最核心的卖点：**从经验中学习，在使用中进化。** + +--- + +## 核心架构拆解 + +咱们这次不讲虚的，直接按官网文档把 Hermes 的架构拆成几层。你会发现它其实不是“一个会聊天的命令行工具”，而是一套把模型、工具、记忆、技能、自动化和安全边界拼到一起的 Agent runtime。 + +image-20260409085456767 + +### 第一层：运行时入口层 + +从官方 Quickstart 和 Features Overview 来看，Hermes 最外层其实是一个统一入口层。 + +这个入口层不只是一套 CLI 命令，它至少覆盖了三类交互面： + +- CLI 会话：直接跑 `hermes` 进入交互式终端，支持多行输入、任务中断、`hermes --continue` 恢复最近会话 +- 消息平台入口：通过 `hermes gateway setup` 接 Telegram、Discord、Slack、WhatsApp，把同一个 Agent 暴露到不同消息渠道 +- 自动化入口：可以直接用自然语言创建定时任务，让 Hermes 通过 gateway 或 cron 在后台周期性执行 + +也就是说，Hermes 不是“先做个命令行，后面再补 Bot”，而是从一开始就把 CLI、消息平台和自动化视为同一套 runtime 的不同入口。这一点很关键，因为它决定了 Hermes 的状态、记忆、技能和权限控制都得跨入口复用。 + +### 第二层：模型与工具执行层 + +官方 Quickstart 里给出的供应商选择其实已经暴露了它的底层结构。Hermes 把“模型调用”和“工具调用”分成了两件事： + +- 模型侧支持 Nous Portal、OpenAI Codex、OpenRouter，以及任何 OpenAI 兼容端点 +- 执行侧则是工具系统，官网 Overview 里明确列了 web search、terminal execution、file editing、browser automation、memory、delegation 这些能力。 + +这意味着 Hermes 的内核不是绑定某一家模型，而是把模型当“推理大脑”，把工具当“行动器官”。 + +你可以把这一层理解成： + +1. 模型负责理解目标、规划步骤、判断是否要调用工具 +2. 工具负责真的去搜网页、改文件、跑终端、开浏览器 +3. 结果再回流给模型，进入下一轮推理 + +这也是为什么它能一边接 OpenAI Codex，一边又强调自带 web search、terminal、browser 这些执行能力。Hermes 的重点不是“聊天模型接得多”，而是“模型和工具之间的闭环完整”。 + +### 第三层：上下文装配层 + +这一层是很多人会忽略，但其实很像“控制中枢”的地方。 + +官网 Features Overview 里提到 Hermes 会自动发现并加载项目里的上下文文件，比如 `.hermes.md`、`AGENTS.md`、`CLAUDE.md`、`SOUL.md`、`.cursorrules`。它还支持用 `@` 引用文件、文件夹、git diff 和 URL，把这些内容动态注入当前消息。 + +这说明 Hermes 在正式推理前，会先做一轮上下文装配： + +- 先吃系统级配置和项目规则 +- 再吃用户当前显式引用的文件和变更 +- 再把记忆、技能、外部 provider 上下文拼进去 +- 最后才把完整上下文交给模型 + +这一步非常像一个“prompt assembly pipeline”，不是单纯地把用户一句话丢给模型。 + +也是因为有这一层，Hermes 才能做到既像编程助手，又像自动化助手，还像聊天 Bot。不同任务的差异，很多不是靠换模型，而是靠换上下文装配结果。 + +### 第四层：持久记忆层 + +这是 Harmes 区别于 OpenClaw 最大的点。 + +这部分官网写得最清楚，也最值得细讲。 + +image-20260409085611925 + +Hermes 的内建记忆不是一个模糊概念，而是两份固定文件加一套历史检索机制： + +- `MEMORY.md`：Agent 的环境记忆，存项目结构、工具坑点、工作流经验、已经验证过的方法 +- `USER.md`：用户画像，存偏好、沟通方式、习惯、雷区、技术水平 + +两份文件默认都在 `~/.hermes/memories/`，而且不是实时乱改的“内存”，而是**在会话开始时作为 frozen snapshot 注入 system prompt**。这点很重要，因为它意味着 Hermes 对持久记忆的使用是受控的、稳定的，不会一边推理一边把 prompt 基础设施搞乱。 + +官网还给了明确的容量设计： + +- `MEMORY.md` 默认 2200 字符，约 800 tokens +- `USER.md` 默认 1375 字符，约 500 tokens + +超了怎么办？不是无限追加，而是让 Agent 自己 consolidate 或替换旧条目。也就是说，Hermes 官方对记忆的理解不是越多越好，而是要把常驻上下文压缩成真正重要的那一小块。 + +除此之外，还有第二条线：历史会话搜索。 + +官方说明 Hermes 会把所有会话存进 SQLite 的 `state.db`，并用 FTS5 做全文检索。真正需要“我们上周是不是讨论过数据库索引策略”这种问题时，它走的是 `session_search` 这条路径，再让模型做摘要，而不是把所有旧对话提前塞进 prompt。 + +所以 Hermes 的记忆层其实是双轨的： + +- 常驻记忆：小而稳定，始终在上下文里 +- 历史检索：大而按需，只有需要时才拉进来 + +这一层的工程味很重，也很像真正能长期运行的 Agent 系统。 + +### 第五层：外部记忆 Provider 层 + +如果你以为 Hermes 的记忆就只有两个 markdown 文件，那就低估它了。 + +官网 Memory Providers 页面写得很明确：内建的 `MEMORY.md` / `USER.md` 会一直开着，同时还可以外挂一个外部 memory provider。当前文档里列了 8 个 provider，Honcho 只是其中之一。 + +当外部 provider 启用时，Hermes 会自动做六件事： + +1. 把 provider 知道的上下文注入 system prompt +2. 在每轮对话前预取相关记忆 +3. 在每次响应后把对话同步给 provider +4. 会话结束时抽取长期记忆 +5. 把内建记忆写入镜像到 provider +6. 给 Agent 暴露 provider 专属工具 + +这一层的意义在于：Hermes 没把记忆架构写死，而是做成了插件化接口。 + +尤其是 Honcho，官方把它定位成“built-in memory 之上的深层用户建模层”。它能做的是： + +- 通过 dialectic reasoning 在会后归纳用户习惯和目标 +- 做跨会话、跨平台甚至多 Agent 的用户画像 +- 用 `honcho_search`、`honcho_context`、`honcho_profile`、`honcho_conclude` 等工具进行语义级记忆检索和结论管理 + +这意味着 Hermes 的长期方向不是“把本地记忆做大”，而是“把内建轻记忆和外部深记忆分层”。这个架构比很多一体化的 Agent 方案要成熟。 + +### 第六层：技能与程序性记忆层 + +如果说持久记忆存的是“你是谁、环境是什么、哪些事实重要”，那技能层存的就是“事情到底怎么做”。 + +官网对 Skills 的定义很直接：它是按需加载的知识文档，遵循 progressive disclosure，默认都放在 `~/.hermes/skills/` 下。这里最关键的不是“技能是 markdown 文件”，而是 Hermes 把技能明确当成了**procedural memory**。 + +image-20260409085819605 + +官方文档里说得非常直白： + +- 完成复杂任务后，Agent 可以创建 Skill +- 试错后找到正确路径，可以保存成 Skill +- 用户纠正了做法，也可以更新 Skill +- Agent 甚至可以删除过时 Skill + +也就是说，技能层其实是 Hermes 对经验沉淀的正式建模。 + +记忆层回答的是： + +- 用户是谁 +- 项目是什么 +- 过去讨论过什么 + +技能层回答的是： + +- 这类任务该怎么做 +- 哪条流程以前走通过 +- 哪些坑已经踩过 + +这个分层很漂亮。因为如果你把“用户喜欢简洁回答”存成 Skill 就太重了；反过来，如果你把“如何部署 Kubernetes 服务”塞进 MEMORY.md 又太脏。Hermes 官方把这两类东西拆开，实际上就是在区分**事实记忆**和**程序记忆**。 + +### 第七层：自动化与并行执行层 + +Hermes 还有一层经常被忽略，就是自动化层。 + +官网 Features Overview 里明确列了这些能力： + +- Scheduled Tasks：通过自然语言或 cron 表达式创建定时任务 +- Subagent Delegation：用 `delegate_task` 启动子 Agent，隔离上下文并限制工具集 +- Code Execution：让 Agent 写 Python 脚本，通过沙箱化 RPC 一次完成多步工具调用 +- Batch Processing：批量并行跑大量 prompt + +这说明 Hermes 并不满足于“单轮问答”。它已经把 Agent 进一步做成了一个可调度系统： + +- 可以定时跑 +- 可以拆子任务并行跑 +- 可以把多轮工具调用折叠成程序执行 +- 可以批处理 + +从架构上看，这一层就是把 Hermes 从“交互式助手”推向“可运营的任务系统”的关键。 + +### 第八层：安全与隔离层 + +最后一层是安全边界，官网 Security 页面把这件事讲得很明白：Hermes 采用的是 defense-in-depth，而不是单点防护。 + +image-20260409085849194 + +它把安全分成五层： + +1. 用户授权 +2. 危险命令审批 +3. 容器隔离 +4. MCP 凭证过滤 +5. 上下文文件扫描 + +展开看，每一层都不是装饰： + +- 用户授权控制的是谁能跟 Agent 说话，支持 allowlist 和 DM pairing +- 危险命令审批控制的是哪些操作必须人在环内确认 +- 容器隔离控制的是命令到底跑在本机、Docker、Singularity 还是远程 SSH +- MCP 凭证过滤控制的是外部 MCP 子进程不该看到哪些环境变量 +- 上下文文件扫描控制的是项目里的恶意提示注入 + +这套设计说明 Hermes 并没有因为“自治”就放弃“边界”。恰恰相反，它把最危险的几个边界都显式化了。 + +### 一句话总结这套架构 + +如果非要用一句工程语言总结 Hermes，我会这么说： + +**Hermes 是一个多入口的 Agent runtime，上面挂着工具执行层、上下文装配层、双轨记忆层、可进化技能层、自动化调度层，底下再用纵深防御安全模型兜底。** + +所以它和 OpenClaw 的真正差别，不只是“一个更聪明，一个更啰嗦”，而是 Hermes 在官方架构上已经把“长期运行、长期学习、长期复用”这三件事当成了第一性原则。 + +--- + +## OpenClaw vs Hermes：全维度对比 + +### 核心设计哲学 + +**OpenClaw**：控制平面优先，人在决策链中心。所有操作需要显式授权，文件驱动的身份系统（SOUL.md）。人定义规则，Agent 执行规则。 + +**Hermes Agent**：学习循环优先，Agent 自动进化。用目标驱动，用结果反馈，用经验优化。人定义目标，Agent 自己找最优路径。 + +### Skill 系统 + +**OpenClaw**：人工编写 Skill，靠文件驱动。开发者写模板，Agent 按模板跑。灵活但依赖人工维护。 + +**Hermes**：从成功经验中自动生成 Skill，持续优化。Skill 会随使用进化，不依赖人工维护。 + +### 记忆能力 + +**OpenClaw**：显式文件记录，需要人工整理维护。没有跨会话学习能力。 + +**Hermes**：分层记忆系统，跨会话保留偏好和经验。越用越懂你。 + +### 安全模型 + +**OpenClaw**：高控制，高权限。文件层面可审计所有行为，但依赖人工配置。 + +**Hermes**：安全沙盒 + 审批检查，默认配置更保守。对非专业用户更友好。 + +### 部署难度 + +**OpenClaw**：有一定门槛。需要折腾配置，理解 SOUL.md 机制。 + +**Hermes**：更轻量，开箱即用，内置 cron 等实用功能。 + +### 适用人群 + +| | OpenClaw | Hermes Agent | +|--|---------|-------------| +| 目标用户 | 硬核开发者、隐私敏感场景 | 想省事的团队、个人用户 | +| 技术背景 | 需要一定折腾能力 | 半技术、小白都友好 | +| 维护成本 | Skill 靠人工写，长期维护成本高 | 自动进化，维护成本低 | +| 透明度 | 高，所有操作文件层面可见 | 中，Skill 生成过程是黑盒 | +| 灵活性 | 极高，SOUL.md 可完全定制 | 中，依赖内置进化机制 | + +--- + +## Hermes 的局限 + +Hermes 也有它的问题，不能盲目吹。 + +**Skill 进化的黑盒问题。** 它的 Skill 生成和优化机制是自动的，这意味着你很难完全理解「为什么这个 Skill 是这样写的」。当 Hermes 生成了一个你不认可的 Skill 时，你没有像 OpenClaw 那样直接改文件的能力。 + +**「成长」需要时间。** Hermes 用久了确实会更懂你，但这个`久`是真的需要一段时间积累。如果你的使用场景是一次性的、或者用几次就不用了，Hermes 的学习能力体现不出来。 + +**对极度隐私敏感的场景仍有局限。** 虽然 Hermes 支持本地部署，但它的 Skill 自动生成机制涉及将执行路径数据写进技能库——这意味着你的使用习惯本身会被结构化存储。对于极度保守的安全要求，这个存储本身也需要保护。 + +--- + +## 怎么选 + +说到底，两者的差异是**「人治」和「自治」的差异**。 + +选 OpenClaw 的情况： +- 你对 Agent 每一步操作需要有完全的可见性和控制权 +- 有特殊的安全合规要求，需要在文件层面审计所有行为 +- 想深度定制 Agent 的能力，开发自己的 Skill 系统 +- 你的场景需要和操作系统、浏览器深度耦合 +- 你有时间和精力折腾配置 + +选 Hermes Agent 的情况： +- 你希望 Agent 能随着使用越来越懂你的工作方式 +- 不想折腾，想快速部署 +- 需要定时自动化任务，内置 cron 调度器很实用 +- 你需要一个更安全的默认配置，减少人工审核负担 +- 团队规模不大，追求轻量灵活 + +**务实建议：可以混用。** + +用 OpenClaw 做主控层，它适合处理需要精确控制的高风险任务。用 Hermes Agent 做轻量执行节点，负责那些重复性的、可以自动学习优化的日常任务。实验性功能隔离到 Hermes 节点上，方便回滚而不影响核心业务。 + +--- + +## 我的看法 + +OpenClaw 代表了一种非常合理的思路：**把控制权还给人类**。它的所有设计——SOUL.md、显式授权、文件审计——都围绕同一个命题：人应该知道 Agent 在做什么，也应该能够干预 Agent 的每一步。 + +这是对的。尤其对技术出身的用户来说，这种控制感是信任的基础。 + +Hermes 代表另一种思路：**让 Agent 真正有用**。它承认了一个现实——大多数人没有时间精力去精细化管理一个 Agent，也不想每次都要停下来审批。所以它把「自主学习」做成了内置能力，把重复性的决策自动化，把人从「监控者」变成「监督者」。 + +两种思路都有市场，也都有局限。 + +OpenClaw 的问题是：它假设了用户愿意且能够持续介入。实际上，大多数人不愿意。开个电脑还要审批一堆东西，时间久了就烦了，要么关掉安全机制，要么干脆不用。 + +Hermes 的问题是：它把「自动进化」做得很漂亮，但这个进化过程对用户是不透明的。Agent 学了什么、为什么这么学、某次决策的依据是什么——这些都是黑盒。用户要么选择完全信任，要么选择不用。中间地带很小。 + +短期看，OpenClaw 在硬核开发者社区还会是主流，尤其在隐私合规要求高的场景里。长期看，能「进化」的 Agent 范式会逐渐成为主流——问题是，这个「进化」机制的透明度和可控性，是它能不能真正普及的关键。 + +Hermes 已经走出了第一步。OpenClaw 不会死，但它需要解决的不只是技术债，还有产品思路上的转型。 + +技术选型没有标准答案。先搞清楚你的场景到底需要什么，再决定用哪个。 + +对了这里要多说一句话，把 OpenClaw 带火的都是中国区用户，那这次的 Hermes 呢？ + +--- + +## 参考来源 + +1. [2026 年AI Agent 双雄对决：OpenClaw vs Hermes Agent 怎么选？](https://cloud.tencent.com/developer/news/3700465) - 腾讯云开发者社区 +2. [狂揽28.4k Star！OpenClaw最新平替Hermes Agent开源](https://zhuanlan.zhihu.com/p/2024913544848623338) - 知乎专栏 +3. [OpenClaw vs Hermes Agent: A Thorough Comparison for Your Use](https://www.youtube.com/watch?v=eJzQuC9Dy3w) - YouTube +4. [OpenClaw vs. Hermes Agent: The race to build AI assistants](https://thenewstack.io/persistent-ai-agents-compared/) - The New Stack +5. [Hermes Agent – OpenClaw's Rival? Differences and Best Use Cases](https://www.turingpost.com/p/hermes) - Turing Post +6. [Hermes Agent 的逆袭：轻量、跨平台、可定制](https://www.sohu.com/a/1004153546_122413774) - 搜狐 +7. [What Is Hermes Agent? The OpenClaw Alternative with a Built-In Brain](https://www.mindstudio.ai/blog/what-is-hermes-agent-openclaw-alternative/) - MindStudio diff --git "a/ai-articles/01-agent-and-coding/Openclaw \344\270\272\345\225\245\350\277\231\344\271\210\347\201\253\357\274\237.md" "b/ai-articles/01-agent-and-coding/Openclaw \344\270\272\345\225\245\350\277\231\344\271\210\347\201\253\357\274\237.md" new file mode 100644 index 0000000..a38fc23 --- /dev/null +++ "b/ai-articles/01-agent-and-coding/Openclaw \344\270\272\345\225\245\350\277\231\344\271\210\347\201\253\357\274\237.md" @@ -0,0 +1,125 @@ +# Openclaw 为啥这么火？ + +> 日期：2026-03-13 + +最近这段时间 OpenClaw 的热度很高，不论是圈内还是圈外的人基本上都对 Openclaw 有所耳闻，差一步就连街坊邻居的大爷大妈们也都知道了。就在这两天 Openclaw 甚至超越了 Linux 和 React ，登顶项目类 Github 榜单第一。这里其实大众有个误区，很多人都认为 Openclaw 已经是 github 第一了，其实并不是，他只是项目类的第一，前面还有许多教程类的 repo。 + +图像 + +不过这并不影响 OpenClaw 的热度。我分析了一下为什么 OpenClaw 能这么火，希望能让你知道 OpenClaw 爆火的前因后果。 + + + +## 首先是 OpenClaw 的开源属性，这是它能火起来的基石。 + + + +因为 OpenClaw 是开源的，他不像 claude 等，属于 AI 私有化的产物，你的生产资料还是属于你自己，相当于你自己的私有产物。 + + + +现在的 AI 赛道，Claude、ChatGPT 这些巨头产品虽然强大，但都是“黑盒”——你的对话数据、你的使用习惯，都被锁在别人的服务器里。对于开发者来说，这就像在别人的田里种地，收成再好也是别人的。OpenClaw 不一样，它把核心代码全部开放，你可以把它部署在自己的服务器上，数据完全自主可控。 + + + +这种“私有化部署”的能力，精准击中了技术人的痛点：既要享受 AI 带来的效率提升，又不想把命根子交到别人手里。GitHub 上的技术极客们，看到这种项目就像鲨鱼闻到血，自发地就开始测试、反馈、提 PR，这种社区自驱力，是任何营销都换不来的。 + + + +## 第二点是自媒体的推动和大模型、云厂商的发力。 + + + +其实 OpenClaw 不是一夜成名的。我记得它之前叫 Clawdbot，那是 1.0 版本，OpenClaw 是迭代后的 2.0。转折点出现在那次改名风波——因为名字谐音触犯了 Anthropic 旗下的 Claude，对方直接发了法律函要求改名。本来这只是个小插曲，结果国内云厂商反应神速，趁着热度直接把 Clawdbot 打包成了云服务器应用模板，用户买完服务器一键就能部署。这波操作，直接把一个开源项目推向了商业化应用的快车道。 + + + +由于 OpenClaw 需要的权限很高，就比如你让他替你发个邮件，他就会需要你的邮件权限，往往这个时候，大家不敢把它部署在自己常用的工作机上，所以刚开始的时候大家都在说买 Mac mini 部署 OpenClaw，所以 Mac mini 的价格也是水涨船高，我之前在电商网站看过 3000 多的 mac mini 已经涨到了 4000 + 了（不得不说这波苹果也赚麻了）。就连咸鱼上二手的 Mac mini 都在升值。 + +image-20260305095055236 + + + +但是大家买来就在思考，我花几千买个这玩意就部署一下 OpenClaw 只为了测试，这性价比也太低了吧。于是各大厂商看到了这个症结点，纷纷在云服务商推出 OpenClaw 应用模板，云服务便宜啊，而且你买来就可以部署这玩意，就当聊天服务器用了，于是就极具性价比了。我记得我买了个 2 核 4G 5M 服务器包年才 99 。 + + + +紧接着，社交媒体彻底点燃了引信。我平时刷的微信、X（原 Twitter）、Telegram、Discord，铺天盖地全是 OpenClaw 的讨论。技术大 V 亲自下场体验，发帖安利；跨圈层的自媒体开始科普，各种文章虽然免不了有标题党，但不得不承认，它们成功让 OpenClaw 出圈了。那段时间，只要你电脑插着网线，就很难避开它的消息。 + + + +## 第三点是精准踩在了时代风口上。 + + + +都说风口上的猪都能飞，更何况 OpenClaw 本身就是长了翅膀的。 + + + +这里就不得不提 OpenClaw 的创始人 Peter Steinberger ，Peter Steinberger 可能不像马斯克那样家喻户晓，但在全球 iOS 开发者社区和技术创业圈里，他的名字绝对如雷贯耳。他是 PSPDFKit 的创始人兼 CEO，也是一位从底层码农一步步走到技术创业顶端的代表人物。 + + + +2011 年左右，Peter 在做项目时需要一套强大的 PDF 渲染工具，但找遍市面都没有合适的。于是他一咬牙，自己写了一个。写完之后他发现：既然我需要，那肯定有成千上万的开发者也需要。于是他决定把这个工具打包成 SDK，PSPDFKit 就此诞生。 + + + +和很多技术人创业的故事一样，最开始也是一个人单打独斗，靠论坛发帖、写技术博客慢慢积累用户。但 Peter 有一个很厉害的地方——他极其注重代码质量和产品体验。PSPDFKit 的文档出了名的详细，API 设计出了名的优雅。这种工匠精神让 PSPDFKit 在开发者口口相传中逐渐站稳了脚跟。 + + + +在技术圈，Peter Steinberger 经常被当作“独立开发者如何做成一家正规公司”的典型案例。他的路径非常清晰：发现痛点 → 做出产品 → 服务好早期用户 → 组建团队 → 全球化扩张。每一步都走得扎实，没有靠融资烧钱，而是靠产品本身造血。 + + + +image-20260305093534702 + +作为 PSPDFKit 的创始人，Peter 在技术圈摸爬滚打多年，对开发者的痛点和社区的玩法门儿清。这次 OpenClaw 的爆火，虽然有一定的偶然性，但背后也离不开他精准的战略眼光。这哥们早就财务自由了，财务自由之后出去旅游了多年，发现旅居的生活不是他想要的，然后回来就搞出来了 OpenClaw，这上哪说理去。这也是为什么这次 OpenClaw 爆火 的原因，因为他身上有一种特质：总能提前看到技术浪潮的方向，并且用最扎实的产品能力把它落地。 + + + +## 第四点是“上门安装” + + + +这个叙事的热度更像是对圈外人说的。 + + + +由于圈外的很多人只知道有这么个龙虾🦞（OpenClaw） ，大家不知道怎么装，怎么玩，于是这就诞生了一个新型市场 --- 上门安装。 + + + +像极了 2000 年初，谁家刚买了电脑，第一件事就是请隔壁老王上门装 Windows 98。五块钱一次，还得管顿饭。那时候装系统是个技术活，启动盘、驱动盘、D 版光盘来回倒腾，装完了还得调试声卡显卡，最后在桌面上给你整个“我的电脑”，才算完工。 + + + +后来是装宽带。电信的人来拉完线，还得有个“技术顾问”上门帮你在 IE 里输账号密码，顺便告诉你那个拨号的小图标要双击。不少人愣是记不住，就把用户名密码贴在显示器边上，跟贴对联似的。 + + + +再后来是装路由器。那时候 Wi-Fi 刚普及，密码设什么、信道怎么调，全是一脸懵逼。上门安装的小哥不仅要搞定网络，还要教大爷大妈怎么把手机连上，连完还得起个 Wi-Fi 名——“你家 Wi-Fi 叫啥？”“叫‘蹭网死全家。” + + + +不过话说回来，这种全民跟风的热潮，虽然有点荒诞，但也挺可爱的。毕竟每一次技术浪潮，都是从“这玩意儿怎么装”开始的。当年装 Windows 的那批人，现在已经在讨论 Kubernetes 了；当年只会拨号上网的大爷，现在也学会用手机买菜了。 + + + +但是这个市场也开始卷起来了，卷到什么程度呢？上门安装的同时还可以打扫卫生。 + + + +87cd805886b3d9ec51a3ed7028199f91 + + + +现在再回头看那次改名风波，简直是神来之笔。原本只是一小撮人在玩的 Clawdbot，因为被大厂发函，瞬间成了“屠龙勇士”。这不仅没打垮它，反而让它的知名度从技术圈破圈，进入大众视野。无数人好奇：到底是什么东西，能让 Anthropic 都坐不住了？这种反向营销，效果比花几百万做广告都好。 + + + +所以你看，OpenClaw 的火，不是偶然。它是产品力（开源 + 好用）、时代机遇（AI 私有化需求爆发）和传播学事件（与大厂的商标争议）以及~~怪诞行为~~（合理）四者完美结合的产物。它已经不仅仅是一个项目，更像是当前这个 AI 狂飙时代的一个缩影。 + + + +原来都是周期啊。 diff --git "a/ai-articles/01-agent-and-coding/QClaw \345\256\236\346\265\213\357\274\214\350\277\231\347\216\251\346\204\217\347\251\266\347\253\237\345\222\213\346\240\267\357\274\237.md" "b/ai-articles/01-agent-and-coding/QClaw \345\256\236\346\265\213\357\274\214\350\277\231\347\216\251\346\204\217\347\251\266\347\253\237\345\222\213\346\240\267\357\274\237.md" new file mode 100644 index 0000000..159e5d5 --- /dev/null +++ "b/ai-articles/01-agent-and-coding/QClaw \345\256\236\346\265\213\357\274\214\350\277\231\347\216\251\346\204\217\347\251\266\347\253\237\345\222\213\346\240\267\357\274\237.md" @@ -0,0 +1,489 @@ +# 现在，请叫 cxuan 智能体！！ + +> 日期：2026-03-18 + +[toc] + +## V 0.1.7 + + + +先说个二逼的事情，我不是说过我之前申请过八个号吗，昨天回家的时候六点多收到了一个内测码，结果我本来想给自己转发的，特么的我竟然给发群里去了。虽然我是秒撤回的，结果还是没防住狼。 + + + +9f702a92f5d8c8c0c316b9b9c0b3c109 + + + +我本来想重新申请，结果显示我申请过了。 + + + +**如果群里有看到我这个窘迫模样的那位，你会不会笑出了猪叫声。** + + + +就在我本以为和这次内测无缘的时候，第二天来到工位，神奇的发现另外一台只用于开热点的手机，有收到了一个内测码，不得不说，感谢 QClaw 厚爱。 + + + +那还等啥玩意，不赶紧开始实测？ + + + +--- + + + +## QClaw 实测 + + + +前几天不是发过一篇图文介绍了一下 WorkBuddy 的接入吗。 + + + +[url] + + + +那时候我在疑惑为什么他的聊天窗口出现在客服消息中，这看起来有点 low。结果 QClaw 一样。。。。。。 + + + +647c183f-c16c-4924-a6d9-02fff3283be9 + + + +目前 QClaw 还不支持图片上传，只能进行文字描述。 + + + +8a3deb61-d174-418a-a9a7-a17427853533 + + + +而且消息暂时不支持双向发送和同步，目前只能在微信公众号与 QClaw 客服沟通，QClaw 客户端目前只是作为消息显示的载体。 + + + +看到这里我笑了：**内测版嘛，客户端先占个坑，功能慢慢补，我懂。** + + + +image-20260317085438287 + + + +我本来想用它给微信好友发个消息试试，结果**一直发送失败**。 + + + +我本来想用它给微信好友发送消息，但是它总是发送失败，我问他原因，它的回复让我并不是很满意，因为看起来他是在**死锁套娃**。 + + + +c0df0ce3-663a-4fc2-a37e-c8b9459776a4 + + + +继续让它找原因，发现问题了，是因为现在 wechat-access 插件还没有实现**主动给用户发消息，只实现了接收消息**。sendText 直接写死着实把我逗笑了。这不是浪费服务器资源吗，QClaw 直接回复一个功能未实现不就可以了吗。 + + + +d29e99c7-2098-4358-9cb4-e607b442796b + + + +76195e9f-9868-4eeb-bd81-9f52ee52ac96 + + + +这暴露了当前 QClaw **插件生态还在建设中**。不过这正是内测的意义 —— 帮他们发现这些"写死"的坑。 + + + +测试过程中我还发现一个现象：只要遇到问题，QClaw 动不动就要我给它解决办法。 + + + +比如我问"为什么发不出去"，它反问"你觉得应该怎么解决"。 + + + +我心想：**是我在内测你还是你在内测我？** + + + +这像极了员工干不出来活为领导怎么办，领导说**你觉得应该怎么办？** + + + +这可能反映了当前 AI 的一个普遍问题 —— **不会自己思考，调用链太短**。遇到卡点就甩锅给用户，而不是尝试自己分析解决。 + + + +不过，QClaw 也不是一无是处。最让我意外的是它的 **Action 能力**。 + + + +--- + + + +我想让它去云服务器上看一下 OpenClaw 的相关配置，给它分配了一个临时账号和权限 —— 它竟然真的可以通过 SSH 登录云端，把相关配置"搂"出来了！ + + + +![image-20260317164710464](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260317164710464.png) + +**这才是智能体该有的样子！** 虽然基础功能还在打磨，但这个核心能力已经有点意思了。 + + + +昨天写了一篇实测 GLM-5 Turbo 的文章，这是第一个让我有遇事不决自己做判断和决策，然后完成任务的模型。文章链接在下面。 + + + +[url] + + + +我又想了一个方案，让它**SSH 上去，grep 一下日志里关于 sendText 的报错，然后根据报错给出三种可能的解决方案，并评估每种方案的可行性。**看看它会怎么做。 + + + +本来我以为它就只会 SSH 上去看看，没想到我告诉它 **"OpenClaw 没有写日志文件，日志只输出到 stdout"** 之后，它的表现让我有点困惑： + + + +它直接告诉我：**不需要日志，光靠代码分析就能给出解决方案！** + + + +然后它真的给出了三个方案，还贴心地打了星标： + + + +- **方案一（⭐⭐⭐）**：修改插件，通过 WebSocket 发送 + + + +- **方案二（⭐）**：用公众号客服消息 API（但我的 AppSecret 被冻结了） + + + +- **方案三（⭐⭐⭐⭐）**：等作者更新 + + + +看到这个回复，我陷入了沉思…… + + + +**这真的是在"思考"吗？** + + + +--- + + + +来，让我们冷静分析一下： + + + +**如果是真思考**：它应该能理解"没有日志"意味着什么，知道自己信息不足，会主动问我要更多信息，或者提出"那我 SSH 上去用 `docker logs` 或者 `journalctl` 看看实时输出"。 + + + +**如果是假思考**：它只是把我之前对话里提到的信息点（sendText写死、wsUrl为空、AppSecret冻结）组合起来，套用一个"问题-方案"的模板输出。看起来很理性，其实是在**装思考**。 + + + +你看它给的方案： + + + +- 方案一：基于我看到的代码（写死 + wsUrl空） + + + +- 方案二：基于我之前提过的"AppSecret被冻结 (有点问题)" + + + +- 方案三：万能兜底方案 + + + +**它没有提出任何新信息，只是在整理我已知的内容。** + + + +真正的思考应该是： + + + +**"既然没有日志文件，那我可以去 `/var/log` 看看有没有别的日志，或者用 `strace` 跟踪一下进程输出，或者修改一下启动脚本把 stdout 重定向到文件……"** + + + +但它没有。 + + + +所以，回到开头那个问题：**它能确定这是在思考吗？** + + + +**我的结论是：不，这不是思考，这是"高级拼接"。** + + + +它像一个很会总结的学生，把课堂笔记整理得井井有条，但并没有真正理解知识之间的联系，也不会举一反三。 + + + +不过这也不全是坏事 —— **至少它学会了闭嘴，不再问我要解决方案了**。 + + + +QClaw 像个 **"正在成长的智能体"**， 它的信息整合能力不错，能理解复杂指令，执行云端操作，而且已经具备了行动力。 + + + +但同时有些还需要打磨的地方：**"伪思考"现象严重**：看起来很理性，其实是在拼接已知信息； + + + +**缺乏真正的推理能力**：不会提出新方案，只会总结旧信息； + + + +**插件生态不完整**：核心功能还是写死的。 + + + +既然它这么会"拼接"，那我再考考它： + + + +**"方案一说要自己实现 WebSocket 发送。你能不能 SSH 上去，用 `tcpdump` 抓一下微信客户端和 wechat-access 之间的通信包，帮我分析一下协议格式？如果抓不到，还有别的办法吗？"** + + + +这次我看你是真思考，还是继续拼接…… ：） + + + +然后他说 + + + +d1239c14-16e0-4fae-bdc4-babe0f574a09 + + + +**这次是真的思考，还是高级拼接？** + + + +让我们来拆解一下： + + + +**如果是拼接**：它应该只会把我之前提到的信息（sendText写死、wsUrl为空、AppSecret冻结）重新排列组合。 + + + +**但这次不一样**： + + + +1. 它读懂了 **AGP协议** —— 这不是我之前给的信息，是它自己从源码里挖出来的 + + + +2. 它发现了 **"能收到消息是因为另一套机制"** —— 这是推理，不是复述 + + + +3. 它给出了 **新的突破口**（wsUrl配置项）—— 这是方向性的建议，不是兜底方案 + + + +最关键的是，它承认了方案一走不通，而不是像之前那样模棱两可地打三颗星。 + + + +**这才是真正的思考** —— 不是整理已知信息，而是**消化信息后得出新结论**。 + + + +## 所以它真的会思考了？ + + + +这次，有点感觉像是真的了。 + + + +之前的"思考"是拼接，这次的"思考"是推理。区别在于： + + + +- **拼接**：把碎片信息摆整齐，看起来很合理，但没有新东西 + + + +- **推理**：消化信息，发现矛盾，提出新问题，给出新方向 + + + +它发现了"能收到消息但 wsUrl 为空"这个矛盾，推断出"一定有另一套机制在工作" —— 这就是推理的痕迹。 + + + +当然，它最后的提问还是暴露了局限性：**它不知道 wsUrl 怎么配，还得问我。** + + + +真正的专家这时候应该主动去翻文档、搜配置、或者 SSH 上去 grep 一下配置文件。 + + + +但至少，**它学会了发现问题，而不是只会总结问题**。 + + + +## V 0.1.8 + + + +今天晚上回来发现 QClaw 又更新了一版，估计内测码又发放了不少。 + + + +首先能够新建对话了。 + + + +![image-20260317220534966](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260317220534966.png) + + + +然后多加了一个灵感广场的功能。 + + + +image-20260317220708336 + + + +这看起来就像是一系列的 skills ，只不过给你做成 UI 的形式了。 + + + +如果你是从灵感广场新加的对话，那么可以在 QClaw 客户端进行对话，但是从微信同步过来的消息，仍旧不支持直接回复。我用灵感广场让他给我解释了一下啥是 transformer 架构。 + + + +![image-20260317221654231](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260317221654231.png) + + + +比如我让他测算了一下我的生辰八卦。果然搞程序的做到最后都喜欢**算卦**。 + + + +image-20260317222429673 + + + +这也太会说话了，我怀疑是不是内置了什么后门故意骗人说好话好让我喜欢用上你这个 QClaw 吧！ + + + +**灵感广场相当于就是 ClawHub 的功能，把一系列的 Skills 做成一个可以浏览、发现、一键安装的广场。这个方向挺好的，Skills 生态丰富起来之后，普通用户不用自己写配置，直接从广场装就行了，门槛低很多。** + + + +从配置里面可以看到用量统计，内测一天 4000 w token ？这也太大方了。 + + + +image-20260318063459963 + + + +技能管理这块可以自由接入各种 skills 。 + + + +image-20260318063613210 + + + +另外，新增加了记忆功能，这个感觉还是很实用，相当于你个人的 soul.md 了，只不过让你从 UI 进行配置。 + + + +image-20260318064742135 + + + +QClaw 依托微信强大的流量入口，从出生以来就就用操心流量的事儿，它担心的是**安全，安全，还是安全。** 如果 QClaw 要成为下一个国民级应用，安全和用户隐私方面一定是重中之重。 + + + +## 写在最后 + + + +这两天的内测体验还是挺有意思的。 + + + +从手滑把内测码发到群里的社死瞬间，到意外收到第二枚码的惊喜；从吐槽它“写死”的代码，到惊叹它 SSH 上云的能力；从怀疑它在“假装思考”，到看到它真正推理出 AGP 协议的那一刻…… + + + +**QClaw 像极了一个正在蹒跚学步的孩子。** + + + +它有天赋——Action 能力、灵感广场、记忆功能，这些骨架已经搭得很漂亮。 + + + +但它也免不了摔跤——插件未完成、伪思考、回复限制，这些都是成长路上必经的坑。 + + + +最有意思的是，在内测的过程中，我发现自己不知不觉从“测试者”变成了“观察者”。我不再只是记录它能做什么、不能做什么，而是开始思考一个更大的问题： + + + +**当 AI 开始学会“发现问题”而不是“总结问题”，当它从“拼接信息”进化到“推理矛盾”，我们与它的关系，会不会也在悄然改变？** + + + +是我们在内测 AI，还是 AI 在内测人类的耐心与期待？ + + + +我不知道答案。 + + + +但我知道，明天醒来，QClaw 可能又会更新一版。 + + + +而我，大概还会继续坐在电脑前，敲下新发现的问题，等着看它会不会给我新的惊喜——或者，新的槽点。 + + + +毕竟，能看到一个东西从 0.1 走向 1.0，本身就是一件挺有意思的事。 diff --git a/ai-articles/01-agent-and-coding/README.md b/ai-articles/01-agent-and-coding/README.md new file mode 100644 index 0000000..6b0e781 --- /dev/null +++ b/ai-articles/01-agent-and-coding/README.md @@ -0,0 +1,44 @@ +# AI Agent 与编程工具 + +Codex、Claude Code、Claw、Agent 工作流、AI 编程工具和真实使用体验。 + +- 2026-07-22 - [Grok Build 被众人唾骂，结果老马把它开源了](./Grok%20Build%20%E8%A2%AB%E4%BC%97%E4%BA%BA%E5%94%BE%E9%AA%82%EF%BC%8C%E7%BB%93%E6%9E%9C%E8%80%81%E9%A9%AC%E6%8A%8A%E5%AE%83%E5%BC%80%E6%BA%90%E4%BA%86.md) +- 2026-07-21 - [Loop 还没玩明白，Graph Engineering 又火了：说白了，就是给 Agent 组个团队](./Loop%20%E8%BF%98%E6%B2%A1%E7%8E%A9%E6%98%8E%E7%99%BD%EF%BC%8CGraph%20Engineering%20%E5%8F%88%E7%81%AB%E4%BA%86%EF%BC%9A%E8%AF%B4%E7%99%BD%E4%BA%86%EF%BC%8C%E5%B0%B1%E6%98%AF%E7%BB%99%20Agent%20%E7%BB%84%E4%B8%AA%E5%9B%A2%E9%98%9F.md) +- 2026-07-16 - [离谱，GPT-5.6 竟然在后台执行了 rm -rf](./%E7%A6%BB%E8%B0%B1%EF%BC%8CGPT-5.6%20%E7%AB%9F%E7%84%B6%E5%9C%A8%E5%90%8E%E5%8F%B0%E6%89%A7%E8%A1%8C%E4%BA%86%20rm%20-rf.md) +- 2026-07-07 - [读懂 Claude Code 架构分析系列，第二篇：Claude Code 是怎样启动的？](./%E8%AF%BB%E6%87%82%20Claude%20Code%20%E6%9E%B6%E6%9E%84%E5%88%86%E6%9E%90%E7%B3%BB%E5%88%97%EF%BC%8C%E7%AC%AC%E4%BA%8C%E7%AF%87%EF%BC%9AClaude%20Code%20%E6%98%AF%E6%80%8E%E6%A0%B7%E5%90%AF%E5%8A%A8%E7%9A%84%EF%BC%9F.md) +- 2026-06-29 - [读懂 Claude Code 架构分析系列，第一篇，开始！](./%E8%AF%BB%E6%87%82%20Claude%20Code%20%E6%9E%B6%E6%9E%84%E5%88%86%E6%9E%90%E7%B3%BB%E5%88%97%EF%BC%8C%E7%AC%AC%E4%B8%80%E7%AF%87%EF%BC%8C%E5%BC%80%E5%A7%8B%EF%BC%81.md) +- 2026-06-24 - [Codex 会把磁盘给烧了？完整复盘来了！](./Codex%20%E4%BC%9A%E6%8A%8A%E7%A3%81%E7%9B%98%E7%BB%99%E7%83%A7%E4%BA%86%EF%BC%9F%E5%AE%8C%E6%95%B4%E5%A4%8D%E7%9B%98%E6%9D%A5%E4%BA%86%EF%BC%81.md) +- 2026-06-09 - [Agents.md 是什么](./Agents.md%20%E6%98%AF%E4%BB%80%E4%B9%88.md) +- 2026-06-09 - [我最近最常用的 10 个 Codex 技巧](./%E6%88%91%E6%9C%80%E8%BF%91%E6%9C%80%E5%B8%B8%E7%94%A8%E7%9A%84%2010%20%E4%B8%AA%20Codex%20%E6%8A%80%E5%B7%A7.md) +- 2026-06-05 - [Codex 一直 Reconnecting？我最后发现，常见就两个坑](./Codex%20%E4%B8%80%E7%9B%B4%20Reconnecting%EF%BC%9F%E6%88%91%E6%9C%80%E5%90%8E%E5%8F%91%E7%8E%B0%EF%BC%8C%E5%B8%B8%E8%A7%81%E5%B0%B1%E4%B8%A4%E4%B8%AA%E5%9D%91.md) +- 2026-06-05 - [为每个任务配一套 harness：Claude Code 里的动态工作流](./%E4%B8%BA%E6%AF%8F%E4%B8%AA%E4%BB%BB%E5%8A%A1%E9%85%8D%E4%B8%80%E5%A5%97%20harness%EF%BC%9AClaude%20Code%20%E9%87%8C%E7%9A%84%E5%8A%A8%E6%80%81%E5%B7%A5%E4%BD%9C%E6%B5%81.md) +- 2026-06-03 - [太顶了，ChatGPT 要和 Codex 搞一起了。](./%E5%A4%AA%E9%A1%B6%E4%BA%86%EF%BC%8CChatGPT%20%E8%A6%81%E5%92%8C%20Codex%20%E6%90%9E%E4%B8%80%E8%B5%B7%E4%BA%86%E3%80%82.md) +- 2026-05-30 - [我花了两天时间，终于把 Codex 额度掉太快的问题整明白了！！](./%E6%88%91%E8%8A%B1%E4%BA%86%E4%B8%A4%E5%A4%A9%E6%97%B6%E9%97%B4%EF%BC%8C%E7%BB%88%E4%BA%8E%E6%8A%8A%20Codex%20%E9%A2%9D%E5%BA%A6%E6%8E%89%E5%A4%AA%E5%BF%AB%E7%9A%84%E9%97%AE%E9%A2%98%E6%95%B4%E6%98%8E%E7%99%BD%E4%BA%86%EF%BC%81%EF%BC%81.md) +- 2026-05-30 - [还在用 Codex 开 xhigh 拉满跑？大错特错](./%E8%BF%98%E5%9C%A8%E7%94%A8%20Codex%20%E5%BC%80%20xhigh%20%E6%8B%89%E6%BB%A1%E8%B7%91%EF%BC%9F%E5%A4%A7%E9%94%99%E7%89%B9%E9%94%99.md) +- 2026-05-28 - [如何把 Codex 用到极致](./%E5%A6%82%E4%BD%95%E6%8A%8A%20Codex%20%E7%94%A8%E5%88%B0%E6%9E%81%E8%87%B4.md) +- 2026-05-25 - [Codex 官方：goal 的正确打开方式](./Codex%20%E5%AE%98%E6%96%B9%EF%BC%9Agoal%20%E7%9A%84%E6%AD%A3%E7%A1%AE%E6%89%93%E5%BC%80%E6%96%B9%E5%BC%8F.md) +- 2026-05-24 - [Codex 把我家网给优化了，我 TM 直接原地起飞了。](./Codex%20%E6%8A%8A%E6%88%91%E5%AE%B6%E7%BD%91%E7%BB%99%E4%BC%98%E5%8C%96%E4%BA%86%EF%BC%8C%E6%88%91%20TM%20%E7%9B%B4%E6%8E%A5%E5%8E%9F%E5%9C%B0%E8%B5%B7%E9%A3%9E%E4%BA%86%E3%80%82.md) +- 2026-05-21 - [Agent Workflow Kit 接入你的项目](./Agent%20Workflow%20Kit%20%E6%8E%A5%E5%85%A5%E4%BD%A0%E7%9A%84%E9%A1%B9%E7%9B%AE.md) +- 2026-05-15 - [Codex 进手机了，这才是 Agent 该有的移动端](./Codex%20%E8%BF%9B%E6%89%8B%E6%9C%BA%E4%BA%86%EF%BC%8C%E8%BF%99%E6%89%8D%E6%98%AF%20Agent%20%E8%AF%A5%E6%9C%89%E7%9A%84%E7%A7%BB%E5%8A%A8%E7%AB%AF.md) +- 2026-05-11 - [我终于把 Codex 的用量扒出来了，原来最贵的不是输出](./%E6%88%91%E7%BB%88%E4%BA%8E%E6%8A%8A%20Codex%20%E7%9A%84%E7%94%A8%E9%87%8F%E6%89%92%E5%87%BA%E6%9D%A5%E4%BA%86%EF%BC%8C%E5%8E%9F%E6%9D%A5%E6%9C%80%E8%B4%B5%E7%9A%84%E4%B8%8D%E6%98%AF%E8%BE%93%E5%87%BA.md) +- 2026-05-08 - [我的 Codex 它把自己改崩了！](./%E6%88%91%E7%9A%84%20Codex%20%E5%AE%83%E6%8A%8A%E8%87%AA%E5%B7%B1%E6%94%B9%E5%B4%A9%E4%BA%86%EF%BC%81.md) +- 2026-05-08 - [Codex 的桌面版宠物比 CC 的好用多了 - 新稿](./Codex%20%E7%9A%84%E6%A1%8C%E9%9D%A2%E7%89%88%E5%AE%A0%E7%89%A9%E6%AF%94%20CC%20%E7%9A%84%E5%A5%BD%E7%94%A8%E5%A4%9A%E4%BA%86%20-%20%E6%96%B0%E7%A8%BF.md) +- 2026-04-29 - [Trae 这波真可以](./Trae%20%E8%BF%99%E6%B3%A2%E7%9C%9F%E5%8F%AF%E4%BB%A5.md) +- 2026-04-21 - [vibe coding 凉了，wish coding 来了](./vibe%20coding%20%E5%87%89%E4%BA%86%EF%BC%8Cwish%20coding%20%E6%9D%A5%E4%BA%86.md) +- 2026-04-18 - [Codex 大更新：从写代码工具变成能操作你电脑的助手](./Codex%20%E5%A4%A7%E6%9B%B4%E6%96%B0%EF%BC%9A%E4%BB%8E%E5%86%99%E4%BB%A3%E7%A0%81%E5%B7%A5%E5%85%B7%E5%8F%98%E6%88%90%E8%83%BD%E6%93%8D%E4%BD%9C%E4%BD%A0%E7%94%B5%E8%84%91%E7%9A%84%E5%8A%A9%E6%89%8B.md) +- 2026-04-16 - [Claude Code 100万上下文：到底是真需求还是营销废话](./Claude%20Code%20100%E4%B8%87%E4%B8%8A%E4%B8%8B%E6%96%87%EF%BC%9A%E5%88%B0%E5%BA%95%E6%98%AF%E7%9C%9F%E9%9C%80%E6%B1%82%E8%BF%98%E6%98%AF%E8%90%A5%E9%94%80%E5%BA%9F%E8%AF%9D.md) +- 2026-04-16 - [Anthropic 这步棋走得漂亮：Claude 的「策略顾问」模式，正在重新定义 AI Agent 的成本方程式](./Anthropic%20%E8%BF%99%E6%AD%A5%E6%A3%8B%E8%B5%B0%E5%BE%97%E6%BC%82%E4%BA%AE%EF%BC%9AClaude%20%E7%9A%84%E3%80%8C%E7%AD%96%E7%95%A5%E9%A1%BE%E9%97%AE%E3%80%8D%E6%A8%A1%E5%BC%8F%EF%BC%8C%E6%AD%A3%E5%9C%A8%E9%87%8D%E6%96%B0%E5%AE%9A%E4%B9%89%20AI%20Agent%20%E7%9A%84%E6%88%90%E6%9C%AC%E6%96%B9%E7%A8%8B%E5%BC%8F.md) +- 2026-04-14 - [如何用10个Claude工作流程每月节省45小时](./%E5%A6%82%E4%BD%95%E7%94%A810%E4%B8%AAClaude%E5%B7%A5%E4%BD%9C%E6%B5%81%E7%A8%8B%E6%AF%8F%E6%9C%88%E8%8A%82%E7%9C%8145%E5%B0%8F%E6%97%B6.md) +- 2026-04-09 - [OpenClaw 凉了，Hermes 已至](./OpenClaw%20%E5%87%89%E4%BA%86%EF%BC%8CHermes%20%E5%B7%B2%E8%87%B3.md) +- 2026-04-07 - [2026 AI Agent](./2026%20AI%20Agent.md) +- 2026-04-04 - [从 IDE 到 CLI，再到 Thread：Codex 所代表的新业态形态](./%E4%BB%8E%20IDE%20%E5%88%B0%20CLI%EF%BC%8C%E5%86%8D%E5%88%B0%20Thread%EF%BC%9ACodex%20%E6%89%80%E4%BB%A3%E8%A1%A8%E7%9A%84%E6%96%B0%E4%B8%9A%E6%80%81%E5%BD%A2%E6%80%81.md) +- 2026-03-31 - [Node.js 22 ESM 加载 bug 导致 OpenClaw 服务宕机全程复盘](./Node.js%2022%20ESM%20%E5%8A%A0%E8%BD%BD%20bug%20%E5%AF%BC%E8%87%B4%20OpenClaw%20%E6%9C%8D%E5%8A%A1%E5%AE%95%E6%9C%BA%E5%85%A8%E7%A8%8B%E5%A4%8D%E7%9B%98.md) +- 2026-03-28 - [我现在想做这么一个东西，有四个 agent 。](./%E6%88%91%E7%8E%B0%E5%9C%A8%E6%83%B3%E5%81%9A%E8%BF%99%E4%B9%88%E4%B8%80%E4%B8%AA%E4%B8%9C%E8%A5%BF%EF%BC%8C%E6%9C%89%E5%9B%9B%E4%B8%AA%20agent%20%E3%80%82.md) +- 2026-03-23 - [今天我的目标就是，我要把 QClaw 接入到微信公众号中。](./%E4%BB%8A%E5%A4%A9%E6%88%91%E7%9A%84%E7%9B%AE%E6%A0%87%E5%B0%B1%E6%98%AF%EF%BC%8C%E6%88%91%E8%A6%81%E6%8A%8A%20QClaw%20%E6%8E%A5%E5%85%A5%E5%88%B0%E5%BE%AE%E4%BF%A1%E5%85%AC%E4%BC%97%E5%8F%B7%E4%B8%AD%E3%80%82.md) +- 2026-03-22 - [微信完全接入 OpenClaw 指南](./%E5%BE%AE%E4%BF%A1%E5%AE%8C%E5%85%A8%E6%8E%A5%E5%85%A5%20OpenClaw%20%E6%8C%87%E5%8D%97.md) +- 2026-03-18 - [QClaw 实测，这玩意究竟咋样？](./QClaw%20%E5%AE%9E%E6%B5%8B%EF%BC%8C%E8%BF%99%E7%8E%A9%E6%84%8F%E7%A9%B6%E7%AB%9F%E5%92%8B%E6%A0%B7%EF%BC%9F.md) +- 2026-03-13 - [Openclaw 为啥这么火？](./Openclaw%20%E4%B8%BA%E5%95%A5%E8%BF%99%E4%B9%88%E7%81%AB%EF%BC%9F.md) +- 2026-03-11 - [现在都开始卷 Claw 了](./%E7%8E%B0%E5%9C%A8%E9%83%BD%E5%BC%80%E5%A7%8B%E5%8D%B7%20Claw%20%E4%BA%86.md) +- 2026-02-07 - [当 Claude Opus 4.6 遇上 GPT-5.3-Codex](./%E5%BD%93%20Claude%20Opus%204.6%20%E9%81%87%E4%B8%8A%20GPT-5.3-Codex.md) + +

返回

diff --git "a/ai-articles/01-agent-and-coding/Trae \350\277\231\346\263\242\347\234\237\345\217\257\344\273\245.md" "b/ai-articles/01-agent-and-coding/Trae \350\277\231\346\263\242\347\234\237\345\217\257\344\273\245.md" new file mode 100644 index 0000000..d47b486 --- /dev/null +++ "b/ai-articles/01-agent-and-coding/Trae \350\277\231\346\263\242\347\234\237\345\217\257\344\273\245.md" @@ -0,0 +1,150 @@ +# Trae 这波真可以 + +> 日期：2026-04-29 + +我今年刚开始接触 AI 的时候，还不知道怎么玩，于是我就下了一个 `Trae` 作为我接触 AI Native 、应用开发和了解 LLM 的入口。 + +我记得当时我是写了个有意思的程序，在这个过程中体会到了 AI IDE 的便利，和传统的 Java IDEA 的区别和使用方式还是非常巨大。 + +也许可能注定了我跟 Trae 有某种阴差阳错的渊源，恰逢在我们家娃稳定下来之后，在合适的时间，遇到了合适的 IDE，缘分这东西谁说的准呢。 + +但是刚开始我没有开通 SOLO，为啥呢，因为我真是没钱。 + +所以这次听说 Trae SOLO 独立出来了，并且内测了，我第一时间就直接下载了。 + +image-20260409235018674 + +下载并且安装完了的界面，嗯，很清爽。 + +![image-20260409235132741](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260409235132741.png) + +然后在我点击 Log in 的时候，弹出的界面，让我这颗中登冥顽不化的心，感受到了心跳的颤抖。 + +我看到了**掘金登录**。 + +“家人们谁懂啊，就像是老友相见分外眼红啊。” + +image-20260409235456974 + +掘金，作为我古法时期写文章最喜欢去的一个社区，那真是一段美好的时光啊，特朗普没上台，国际局势稳定，金子没这么贵，赚钱没那么难的日子。 + +作为掘金那时候没几个博主有的社区建设者，万粉博主，优秀创作者，提提意见掘金就得照做，亲眼目睹掘金被收购的人（~~太装了哥，真受不了了~~），这怎么能不热泪盈眶呢。 + +image-20260409235916769 + +于是这波必须要通过掘金登录一下。 + +登录完成后居然。。。要内测码？？？？ + +image-20260410060915552 + +我心想完了，我这也不认识 Trae 社区的人啊，怎么办？幸好我之前跟掘金官方的同学关系不错，直接舔到了内测码。 + +>更重要的是，我可是不仅舔了一个内测码，我舔了 100 + 个内测码！！！ +> +>内测码见文末！！！ + +不过话又说回来了，为什么 Trae 开发了一个 IDE，里面本来就带着 SOLO 模式，这次为什么又要独立出来搞一个 Trae SOLO CN？ + +我让它自己回答了下。 + +| 功能维度 | Trae Solo CN | Trae CN的Solo模式 | +| :--------------- | :---------------------------------------------------------- | :----------------------------------------------- | +| **产品形态** | 独立端产品（PC端+Web端） | IDE中的工作模式 | +| **访问方式** | 通过 [https://solo.trae.cn](https://solo.trae.cn/) 直接访问 | 在Trae CN IDE中切换开启 | +| **核心模式** | 双模式设计：Code与MTC (More Than Code) | 单一Solo模式 | +| **文件处理能力** | 支持多种格式文件：会议速记、原始数据、手绘原型草图等 | 主要处理代码文件 | +| **能力范围** | 泛化到整个互联网产研上下游，跨界处理多种任务 | 主要聚焦于代码开发 | +| **项目构建** | 支持从零构建完整项目 | 支持从零构建完整项目 | +| **AI能力** | 自动拆解任务、生成多文件代码、安装依赖、运行调试 | 自动拆解任务、生成多文件代码、安装依赖、运行调试 | +| **实时预览** | 支持Webview实时预览网页效果 | 支持Webview实时预览网页效果 | +| **模型切换** | 支持切换内置模型与自定义接入模型 | 支持切换内置模型与自定义接入模型 | +| **跨平台** | 同时支持PC端和Web端 | 仅在IDE内运行 | +| **独立访问** | 无需安装IDE，直接通过浏览器访问（当然可以下载PC 端） | 需要先安装Trae CN IDE | +| **轻量级** | 轻量级设计，适合快速任务 | 作为IDE的一部分，功能更全面但更重量级 | + +>总结来说，Trae Solo CN是一个更加独立、轻量、多功能的AI开发工具，而Trae CN的Solo模式则是作为IDE的一部分，更加专注于代码开发场景。Trae Solo CN的独特优势在于其跨界能力和独立访问的便捷性。 + +solo 模式之前可是付费买的，现在直接免费用了，香的一批。 + +一直不清楚 MTC 和 Code 的差别是什么，问了一下 Trae。 + +![image-20260429111709471](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260429111709471.png) + +就类似 CC 中的 plan mode，先把计划列下来，然后分批次执行，适合写 Spec 之后，再上手干活。 + +![image-20260429111836878](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260429111836878.png) + +也就是说，Code 模式可能考虑的没有 Plan Mode 那么全面，但是适合直接出 MVP 版本。 + +skills 插件商店里面有很多，甚至支持了 alipay 和 douyin 的 skills。 + +![image-20260429135624944](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260429135624944.png) + +支付宝和抖音的 skills 都有，这说明啥？说明字节系的生态整合能力是真强。 + +## 上手干了点活 + +光看不练假把式，我直接拿它写了个小工具。 + +用的是 Code 模式，因为我这人比较急，不喜欢先列计划再干活，直接开干比较适合我。 + +我给它的需求很简单：写一个 Python 脚本，把 Markdown 文件里的图片链接批量下载到本地。这个需求我之前用 Claude Code 也写过，正好可以对比一下。 + +image-20260429150843654 + +Trae SOLO 的响应速度是真的快。它先把整体思路给我过了一遍，然后就开始写代码了。整个过程大概一分钟，脚本就出来了。 + +不过要说跟 Claude Code 比的话，各有千秋吧。 + +Claude Code 的优势在于它更"稳"。你给它一个复杂需求，它会先用 plan mode 把计划列得很清楚，然后一步步执行。出错的概率比较低，但速度确实慢一些。 + +Trae SOLO 的优势在于"快"和"直觉"。它不太纠结完美方案，先给你一个能跑的版本，然后你再迭代。这种工作方式其实挺适合快速原型开发的。 + +## MTC 模式试了试 + +后来我也试了一下 MTC 模式，让它帮我规划一个稍微复杂点的项目——一个简单的文章管理后台。 + +MTC 模式确实更像 Claude Code 的 plan mode。它会先分析你的需求，列出技术选型、目录结构、数据库设计，然后生成一个详细的执行计划。你确认之后，它才开始动手。 + +这个模式适合那种你还没想清楚要怎么做、需要 AI 帮你理清思路的场景。比如你想做个东西，但不确定用什么技术栈，MTC 会给你几个方案让你选。 + +但说实话，对于我这种已经比较清楚自己要什么的人来说，MTC 有点"过于谨慎"了。我更喜欢 Code 模式的"先干了再说"。 + +## 聊点不足 + +当然也不是没毛病。 + +我自己遇到的：对话历史偶尔莫名丢失，重启一下就好；生成的代码有时候有小 bug，得手动修。 + +社区反馈比较集中的遗憾有两个。一个是没跟飞书打通——很多人用飞书对接需求，要是能实现会议纪要同步、群聊需求直接对接 SOLO，协作体验会更流畅。另一个是不支持定时任务，想让它定期生成日报周报还不行。 + +还有就是定价问题。现在内测免费用，但正式版怎么收费？字节的风格一向是先免费铺量再商业化，后面大概率会有收费方案，具体多少谁也不知道。 + +## 最后 + +2026 年了，AI 编程工具已经不是「要不要用」的问题，而是「用哪个」的问题。 + +Cursor 功能最全但贵，Claude Code 最稳但偏命令行，Windsurf 中规中矩，Trae SOLO 胜在免费且轻快。对于国内开发者来说，Trae 还有个天然优势——中文理解好、掘金账号打通、字节生态集成。 + +作为一个从掘金时代就关注字节系产品的老用户，看到 Trae SOLO 这样的产品，说实话挺欣慰的。它不完美，但方向对了，体验也在线。 + +如果你也在找一个趁手的 AI IDE，不妨下载试试。 + +至于我嘛，准备拿它来重构一下我那个半死不活的个人项目。毕竟有了趁手的工具，不干点啥总觉得浪费。 + +--- + +找 Trae 的朋友要了 100 个内测码，这次可真是大手笔！！ + +KLnznuH7 + +https://solo.trae.cn/invitation/KLnznuH7 + +uwJweE8n + +https://solo.trae.cn/invitation/uwJweE8n + +两个码，但是 100 多个名额，懂的都懂，先到先得。 + +内测码都给你们舔来了，**我要个三连不过分吧？** diff --git a/ai-articles/01-agent-and-coding/codex-maxxing-assets/page-01.png b/ai-articles/01-agent-and-coding/codex-maxxing-assets/page-01.png new file mode 100644 index 0000000..cdb8c2a Binary files /dev/null and b/ai-articles/01-agent-and-coding/codex-maxxing-assets/page-01.png differ diff --git a/ai-articles/01-agent-and-coding/codex-maxxing-assets/page-05.png b/ai-articles/01-agent-and-coding/codex-maxxing-assets/page-05.png new file mode 100644 index 0000000..ceafd5c Binary files /dev/null and b/ai-articles/01-agent-and-coding/codex-maxxing-assets/page-05.png differ diff --git a/ai-articles/01-agent-and-coding/codex-maxxing-assets/page-07.png b/ai-articles/01-agent-and-coding/codex-maxxing-assets/page-07.png new file mode 100644 index 0000000..93c7389 Binary files /dev/null and b/ai-articles/01-agent-and-coding/codex-maxxing-assets/page-07.png differ diff --git a/ai-articles/01-agent-and-coding/codex-maxxing-assets/page-10.png b/ai-articles/01-agent-and-coding/codex-maxxing-assets/page-10.png new file mode 100644 index 0000000..1c72f0b Binary files /dev/null and b/ai-articles/01-agent-and-coding/codex-maxxing-assets/page-10.png differ diff --git a/ai-articles/01-agent-and-coding/codex-maxxing-assets/page-16.png b/ai-articles/01-agent-and-coding/codex-maxxing-assets/page-16.png new file mode 100644 index 0000000..66ba170 Binary files /dev/null and b/ai-articles/01-agent-and-coding/codex-maxxing-assets/page-16.png differ diff --git a/ai-articles/01-agent-and-coding/codex-maxxing-assets/page-19.png b/ai-articles/01-agent-and-coding/codex-maxxing-assets/page-19.png new file mode 100644 index 0000000..861da5c Binary files /dev/null and b/ai-articles/01-agent-and-coding/codex-maxxing-assets/page-19.png differ diff --git a/ai-articles/01-agent-and-coding/codex-maxxing-assets/page-22.png b/ai-articles/01-agent-and-coding/codex-maxxing-assets/page-22.png new file mode 100644 index 0000000..35f55c4 Binary files /dev/null and b/ai-articles/01-agent-and-coding/codex-maxxing-assets/page-22.png differ diff --git a/ai-articles/01-agent-and-coding/codex-maxxing-assets/page-24.png b/ai-articles/01-agent-and-coding/codex-maxxing-assets/page-24.png new file mode 100644 index 0000000..51e540b Binary files /dev/null and b/ai-articles/01-agent-and-coding/codex-maxxing-assets/page-24.png differ diff --git "a/ai-articles/01-agent-and-coding/vibe coding \345\207\211\344\272\206\357\274\214wish coding \346\235\245\344\272\206.md" "b/ai-articles/01-agent-and-coding/vibe coding \345\207\211\344\272\206\357\274\214wish coding \346\235\245\344\272\206.md" new file mode 100644 index 0000000..c4e5d52 --- /dev/null +++ "b/ai-articles/01-agent-and-coding/vibe coding \345\207\211\344\272\206\357\274\214wish coding \346\235\245\344\272\206.md" @@ -0,0 +1,161 @@ +# vibe coding 凉了，wish coding 来了 + +> 日期：2026-04-21 + +2025 年，vibe coding 是最火的词。 + +Karpathy 提出来之后，全行业都在讨论：你描述需求，AI 写代码，方向你来判断，结果来验收。这个模式听起来很美好，也确实解决了很多问题。 + +但到了 2026 年，问题开始暴露了。 + +image-20260421152607242 + +vibe coding 的本质是什么？你给 AI 一个大致需求，AI 自己猜你要什么。你说「做一个感觉像高端产品的登录页面」，AI 给你一堆深色渐变加玻璃态。你说「帮我搭一个后端」，AI 给你一个 REST API架子，你也不知道为什么选这个结构。 + +这种凭借直观感受的方式，快的时候是真快。但出来的代码质量取决于 AI 猜得对不对。猜对了是惊喜，猜错了是惊吓。 + +image-20260421152641388 + +vibe coding 暴露的根本问题是：它还是在让你**大概描述**而不是**精确表达**。你给 AI 的信息是模糊的，AI 的输出自然也是模糊的。 + +--- + +## 新的词出来了：intent is the new syntax + +McKinsey 有一句话我觉得说得很准： + +> Over the next decade, AI-assisted programming will let developers specify intent through a mix of formal programming languages and natural language + +翻译过来就是：未来十年，AI 辅助编程会让开发者通过正式编程语言和自然语言的混合来表达意图。 + +注意这里的核心词是 **intent**——意图。 + +Everest Group 的说法更直接：Intent is the new syntax 意图就是新的语法。 + +这两句话合在一起，说的是同一件事：编程的最小单元，正在从**语法**变成**意图**。 + +image-20260421152722254 + +以前你学编程，是学怎么用正确的语法表达一个指令。现在你学编程，是学怎么用精确的语言描述你要什么。 + +这不是工具变了，是人会编程这件事的定义变了。 + +--- + +## wish coding 的正经名字 + +有人在给这个现象起了个正经名字：intent-oriented programming，意图导向编程。 + +它的核心主张是：编程语言应该无限接近人的思考方式，而不是机器的执行方式。你想的是「用户登录之后看到首页」，而不是「调用 /auth/login 接口然后重定向到 /home」。 + +这个转变的滑梯很长： + +- 最早期：写机器码 +- 然后：写汇编 +- 然后：写高级语言 +- 现在：用自然语言描述意图，AI 转换成代码 + +image-20260421152820950 + +每一步都是在用更接近人思考方式的方式编程。 + +所以 `wish coding` 这个名字虽然听起来有点调侃，但它描述的现象是真实的：你不是写代码，你是在许愿。你说「我要一个能用的登录系统」，AI 给你一个。 + +许愿的问题是：你得把你的愿望说清楚。 + +vibe coding 阶段，你大概说说就行，AI 会猜。intent-oriented 阶段，你说模糊了，AI 就给你模糊的结果。 + +区别在于：vibe coding 是感受驱动，intent-oriented 是规格驱动。 + +--- + +## 为什么 vibe coding 先火，intent-oriented 后到 + +这跟 AI 能力的进化阶段有关。 + +vibe coding 能跑起来，是因为 2024-2025 年的 AI 已经能理解**大概要什么**，并且能生成看起来像样的代码。这个阶段 AI 的能力是我猜你大概要这个，对模糊指令有一定的容忍度。 + +但问题是大概像样不等于能用。出来的代码往往有这些问题：边界情况没处理、安全隐患存在、架构不适合长期维护。测试能跑，一上线就出问题。 + +intent-oriented 需要的是：AI 能精确理解你说的每一句话，并把它转化成严格对应的代码实现。你说处理并发的时候要考虑 token 过期，AI 不会漏掉这个细节。你说错误信息要包含原始请求 ID，AI 不会随便写一句请求失败。 + +这种精确度，需要更强的 AI 能力，也需要更规范的表达方式。 + +所以 vibe coding 是 AI 早期的产物，intent-oriented 是 AI 成熟一点的产物。这不是谁取代谁，是 AI 能力上了一个台阶，许愿的方式也需要升级。 + +--- + +## Augment Code 做的事 + +有个产品叫 Augment Code https://www.augmentcode.com/product/intent，它的定位能说明 intent-oriented programming 现在在发生什么。 + +![image-20260420213142856](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260420213142856.png) + +它的模式是这样的：你给一个 intent spec，AI 拆解成多个 agent 并行工作。Auth Token Agent 做认证模块，Gateway Middleware Agent 做网关验证，两个 agent 共享同一个规格文档，各自实现自己的部分，最后串起来。 + +关键点不是多个 agent，而是你给的指令是**结构化的规格文档**，不是一句帮我加上 JWT 认证。 + +image-20260421152935575 + +结构化意味着：每个字段的格式是定的，每个接口的输入输出是定的，边界情况是定的。AI 对着规格做，做完验收也对着规格验收。 + +这不是 vibe coding，这是 intent-oriented。 + +--- + +intent-oriented 的问题是：它要求你先想清楚你要什么。 + +vibe coding 的好处是探索阶段你可以先丢一个模糊的想法，看 AI 给你什么，然后慢慢调整。这个过程不需要你一开始就把所有细节想明白。 + +intent-oriented 要求你先写规格，再让 AI 实现。这对有经验的开发者来说可能是自然流程，对探索阶段的项目来说有时候反而是限制。 + +所以这两者不是非此即彼的关系： + +- 探索阶段，vibe coding 快速验证想法 +- 方向明确了，切换到 intent-oriented 做扎实实现 + +McKinsey 的说法也是这个意思。 + +> 未来十年，是formal 编程语言 + 自然语言的混合，而不是纯自然语言。formal 部分是规格，自然语言部分是表达意图。 + +--- + +## + +我自己在用 AI coding 工具的时候，这个转变的感受是很明显的。 + +image-20260421153016806 + +一开始用 vibe coding，我丢一句帮我做一个博客系统，AI 给我一个能跑的架子。我觉得很爽。 + +但深入用下去，我发现**能跑**和**能用**之间差了很多东西：分类标签的实现有问题、搜索功能的边界情况没处理、SEO 的 meta 标签不规范。AI 帮我快速搭了一个架子，但每个细节都需要我重新排查。 + +后来我换了一个方式：先在脑子里想清楚我要的博客系统有哪些功能模块、每个模块的输入输出是什么、错误怎么处理。想到了，用结构化的方式告诉 AI。 + +结果完全不一样。AI 给的东西一开始就是对的，不需要我反复修。 + +不是 AI 变了，是我的表达方式变了。 + +--- + +## + +vibe coding 不是凉了，是升级了。 + +它没有被抛弃，它进化成了 intent-oriented programming。许愿的方式从大概描述感受变成了精确描述规格。 + +这个转变的本质不是工具变了，是人对 AI 的用法变了：你给 AI 的信息质量越高，AI 给你的结果质量也越高。 + +Vibe coding 是 AI 帮你快速探索，intent-oriented 是 AI 帮你精确实现。 + +两个都用，比非此即彼更实际。 + + + +Sources: +- [Intent is the New Syntax: Why Vibe Coding Represents a Shift - Everest Group](https://www.everestgrp.com/blog/intent-is-the-new-syntax-why-vibe-coding-represents-a-shift-in-software-development-blog.html) +- [Vibe Coding: Toward an AI‑Native Paradigm - Vinay Bamil](https://arxiv.org/html/2510.17842v1) +- [Build with Intent | Augment Code](https://www.augmentcode.com/product/intent) +- [Intent-Oriented Programming: Bridging Human Thought and AI Machine Execution](https://kotrotsos.medium.com/intent-oriented-programming-bridging-human-thought-and-ai-machine-execution-3a92373cc1b6) +- [Unlocking the value of AI in software development - McKinsey](https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/unlocking-the-value-of-ai-in-software-development) +- [Vibe Coding in 2026: How AI Is Changing the Way Developers Write Code](https://daily.dev/blog/vibe-coding-2026-ai-changing-how-developers-write-code) diff --git "a/ai-articles/01-agent-and-coding/\344\270\272\346\257\217\344\270\252\344\273\273\345\212\241\351\205\215\344\270\200\345\245\227 harness\357\274\232Claude Code \351\207\214\347\232\204\345\212\250\346\200\201\345\267\245\344\275\234\346\265\201.md" "b/ai-articles/01-agent-and-coding/\344\270\272\346\257\217\344\270\252\344\273\273\345\212\241\351\205\215\344\270\200\345\245\227 harness\357\274\232Claude Code \351\207\214\347\232\204\345\212\250\346\200\201\345\267\245\344\275\234\346\265\201.md" new file mode 100644 index 0000000..a3e2101 --- /dev/null +++ "b/ai-articles/01-agent-and-coding/\344\270\272\346\257\217\344\270\252\344\273\273\345\212\241\351\205\215\344\270\200\345\245\227 harness\357\274\232Claude Code \351\207\214\347\232\204\345\212\250\346\200\201\345\267\245\344\275\234\346\265\201.md" @@ -0,0 +1,295 @@ +# 为每个任务配一套 harness：Claude Code 里的动态工作流 + +> 日期：2026-06-05 + + +![image-20260605092343445](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260605092343445.png) + +大家好，我是 cxuan，一个和 AI Agent 互相折磨的 builder。 + +先说个我自己的事。 + +之前我用 `/goal` 挂过一个跑了 75 小时的任务。当时还挺得意，觉得这就是 agent 的终极形态，交代一句，它自己埋头干三天。 + +结果收益和它烧掉的 token 以及时间根本不成正比。 + +任务跑到后半程，它开始自我陶醉：我一开始定的约束，跑着跑着就当没看见了。 + +我一直认为的是我的 Prompt 或者我的目标设定有问题。 + +直到上周，Claude Code 发布了新的 Opus 4.8 模型，并介绍了其中有一项叫做 dynamic workflows（动态工作流）的特性之后，我才觉得，我这个 goal 也许非常适合使用 dynamic workflows。 + +这个特性说的是，Claude 现在能即时写出每个任务自己的 harness 了。 + +默认的 Claude Code harness 是为写代码做的，但它对很多别的类型的任务也好用，比如 Research（研究）、安全分析、agent teams，或者 Code Review（代码审查）。 + +Workflows 让你能动态创建这种 harness，它使得 Claude 能在内部更原生地解决上面这些问题。你还能把这些 workflow 分享给别人、反复复用。 + +我会结合这篇文章和自己上手 workflows 的初步体会和心得，来和大家聊聊 dynamic workflows。 + +> 话虽如此，最佳实践仍在成形中！dynamic workflows 往往更费 token，所以什么时候用、怎么用，得仔细想清楚。 + +--- + +## 示例 prompt + +在进入技术细节之前，我来给你抛出几个示例 prompt，让你对 workflows 这个东西，有点感觉。 + +> “这个测试大概每 50 次跑会挂 1 次。建一个 workflow 来复现它，提出几种理论，并在 worktree 里对抗式地验证它们。/goal 在某一种理论成立之前别停。” +> +> +> +> “用一个 workflow，翻一遍我最近的 50 个 session，从里面挖出我反复在做的那些纠正，把高频出现的变成 CLAUDE.md 规则。” +> +> +> +> “拿我的商业计划，跑一个 workflow，让不同的 agent 分别从投资人、客户、竞争对手的角度把它琢磨清楚。” +> +> +> +> “这里有一个装了 80 份简历的文件夹，用一个 workflow 按后端岗位给它们排名，并把前十名复核一遍。用 AskUserQuestion 工具来问我，问出一份评分标准。” +> +> +> +> “我得给这个 CLI 工具起个名。用一个 workflow 头脑风暴出一堆候选，再跑一场淘汰赛选出前三名。” +> +> +> +> “用一个 workflow 把我们代码里的 User 模型全局重命名成 Account。” +> +> +> +> “过一遍我的博客草稿，用一个 workflow 把里面每一条技术声明都对着代码库核一遍——我不想发出去任何错的东西。” + +--- + +大家在用 AI Agent 的时候，是不是会经常这么干，在一个 session（会话）里面，让 Claude Code 同时完成规划和执行工作？ + +对很多写代码的任务，这套非常有效； + +但碰上长时间运行、大规模并行、需要高度结构化的对抗性任务，它处理的并不好。 + +原因在于：Claude 在单个 context window 里啃一个复杂任务的时间越长，就越容易陷入下面这三种模式。 + +* **Agentic laziness（agent 偷懒）**指的是 Claude 在一个特别复杂、多环节的任务还没干完时就停下，做了一部分就宣布任务完成了，比如一次安全审查有 50 项，它处理了其中 20 项就收工了。 + +* **Self-preferential bias（自我偏袒）**指的是 Claude 倾向于偏爱自己产出的结果或发现，尤其是在被要求对照评分标准去验证或评判的时候。 + +* **Goal drift（目标漂移）**指的是跨越多轮对话之后，对最初目标的忠实度会一点点流失。 + + 在 compaction（上下文压缩）之后尤其明显。像是边界情况要求、例如“别做 X” 的这类约束，它很容易在过程中丢掉。 + +这三种里，我对第三种最有发言权。我开头那个跑了 75 小时的 goal，翻车翻的就是这儿，它把我的规矩给忘了。 + +创建一个 workflow 有助于对抗这些问题，它用一组各自拥有独立 context window、目标聚焦又彼此隔离的 Claude 来协同作业。 + +--- + +## 动态工作流 vs 静态工作流 + +你以前可能用过 Claude Agent SDK 或者 `claude -p` 来创建静态工作流，这种方式会把多个 Claude Code 实例协同到一起。 + +有了 Claude Opus 4.8 和 dynamic workflows 之后，Claude 现在已经聪明到能为你的具体用例写出一套量身定制的 harness。 + +![image-20260605092358458](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260605092358458.png) + +--- + +## 几个好用的模式 + +你只需要让 Claude 做一个 workflow 就能开始用 dynamic workflows，或者用触发词 `ultracode` 来确保 Claude Code 给你建一个。 + +但 dynamic workflows 它有几种运作模型，你脑子里把这些装上，下次就能帮你判断什么时候该用、以及怎么通过 prompt 去引导 Claude。 + +Claude 在搭 workflow 时，常会用到、也常会组合起来的，有下面这几种模式： + +![image-20260605092409727](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260605092409727.png) + +* **Classify-and-act（先分类再行动）**：用一个分类 agent 判断任务的类型，再根据任务路由到不同的 agent 或不同的行为。或者，在末尾用一个分类 agent 来决定最终输出。 + +* **Fan-out-and-synthesize（大活拆开再合并）**：把一个任务拆成许多更小的步骤，每一步跑一个 agent，再把这些结果合并起来。当小步骤数量很多，或者每一步都受益于自己那份干净的 context window、好让它们互不干扰、不交叉污染时，这招特别好用。 + + 合并那一步是个 barrier，起到屏障作用，等所有 agent 执行完成后，再把它们的结构化输出并成一个结果。 + +* **Adversarial verification（对抗式核查）**：每 fork（派生）出一个 agent，就会再派生出一个或几个独立的 agent，对照一份评分标准或判据，对抗式地验证前者的输出。 + +* **Generate-and-filter（生成再过滤）**：就某个主题生成一批想法，再按评分标准或通过验证去过滤，去掉重复的，只留下质量最高、经过检验的那些。 + +* **Tournament（淘汰赛）**：不去分工，而是让 agent 们在同一件事上竞争。派生 N 个 agent，各用不同的思路去尝试同一个任务。然后用 prompt 或模型充当评委，两两比较地评判结果，直到选出一个胜者。 + +* **Loop until done（循环到完成）**：对那种工作量未知的任务，不要设固定的轮数，而是循环地派生 agent，直到满足某个停止条件（没有新发现了，或者日志里不再有报错）。 + +这六个不用全记。我自己最常想起来用的就两个：fan-out（把大活拆开并行跑）和对抗式核查（让一个 agent 专门去挑另一个的错）。一个治慢，一个治它自我偏袒。 + +剩下那几个，遇到对的场景自然会想起来。 + +--- + +Thariq 有句话我很认同：**他发现 workflows 用在非技术工作上，有时反而更有用。** + +下面他给出了适用于 workflows 的几种方式。 + +### 迁移与重构 + +Bun 就是用 workflows 从 Zig 重写成 Rust 的。 + +关键是把任务拆成一连串需要逐个处理的步骤，比如调用点、失败的测试、各个模块等等。为每一处修复在一个 worktree 里派生一个 subagent 去改，再让另一个 agent 对抗式地审查，然后把它们合并。可以考虑告诉 agent 别用太吃资源的命令，这样你就能最大化并行，又不至于把机器上的资源耗光。 + +### 深度研究 + +Claude Code 发布了一个深度研究 skill（`/deep-research`），它就用了 dynamic workflows。 + +具体来说，它会进行多路网络搜索，抓取来源，对抗式地核查这些来源的声明，最后合成一份带引用的报告。 + +但这类研究不止能用在网络搜索上。比如让 Claude 从 Slack 的上下文里汇编一份状态报告，或者通过深入探查一个代码库来研究某个功能是怎么实现的。 + +### 深度核查 + +![image-20260605092433094](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260605092433094.png) + +反过来，如果你有一份报告，想把它引用的每一条事实声明都核查、溯源，那你可以生成一个 workflow。 + +让一个 agent 找出所有事实声明，再为每一条派生一个 subagent 去细查。 + +你还可以再加一个验证 agent，去检查那个负责溯源的 subagent，确保它找的来源质量过硬。 + +### 排序 + +![image-20260605092444968](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260605092444968.png) + +你可能有一份清单，想按某个定性指标来排序，而你相信 Claude Code 擅长评判这个指标，比如把支持工单按 bug 的严重程度排序。 + +但如果你想在一个 prompt 里排 1000 多行，质量会下降，也塞不进 context。 + +换个做法：用上面的架构模式跑一场淘汰赛，用一条两两比较的 agent 流水线（相对判断比绝对打分更可靠），或者并行做分桶排名再合并。 + +每一次比较都是它自己的一个 agent，于是那个确定性的循环负责维护赛程表，只有当前的排序顺序留在 context 里。 + +### 记忆与规则遵守 + +![image-20260605092456622](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260605092456622.png) + +如果有一组特定的规则，你发现 Claude 老是漏掉、老是做不好，哪怕写进了 CLAUDE.md 也不行，那就建一个 workflow。 + +列出一份必须由验证 agent 检查的规则，一条规则配一个验证 agent。再造一个「怀疑论者」人设的 subagent 去复核这些规则、确保它们本身合理，这能帮你避免太多误报。 + +反方向也成立。 + +从你最近的 session 和 code review 评论里，挖出你反复在做的那些纠正，用并行 agent 把它们聚类，对每个候选规则做对抗式验证（这条规则真能拦下一个真实的错误吗？），最后把活下来的那些提炼回 CLAUDE.md。 + +### 根因调查 + +调试最有效的方式，是想出几个互相独立的假说再逐一验证。 + +但如果你只用一个 context window，Claude 会有“自我偏袒” 。 + +一个 workflow 能从结构上挡住这一点：派生多个 agent，从互不重叠的证据里各自生成假说。 + +比如，给日志、文件、数据各派一个独立的 agent。每个假说接着面对一组验证者和反驳者。 + +这不只用于代码。workflows 能用在销售（三月份销量为什么掉了？）、数据工程（这条 pipeline 为什么挂了？），或者任何复盘场景上。 + +### 规模化分流（triage） + +![image-20260605092514131](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260605092514131.png) + +每个团队都有一个支持队列、bug 报告，或者别的什么靠人力处理不完的积压。 + +一个 triage workflow 会给每个条目分类，跟已经在跟踪的去重，然后采取行动。行动可能是尝试修复，也可能是上报给人来处理。 + +triage workflow 有个好用的模式叫 quarantine（隔离）：禁止那些读取不可信公开内容的 agent 去执行高权限操作，这些操作改由负责据此信息行动的那批 agent 来完成。 + +把 triage workflow 配上 `/loop`，就能让 Claude 持续不断地干这件事。 + +### 探索与品味 + +探索一个问题的不同解法时，workflows 也很有用，尤其当问题是偏品味的（比如设计或起名），又能用一份评分标准来衡量的时候。 + +可以让 Claude 探索一堆方案，并给一个审查 agent 一份“好方案长什么样”的评分标准。 + +当审查 agent 认为已经达标，任务就算完成。 + +方案也可以基于这份评分标准、用一场淘汰赛的方式来排序或挑选。 + +### Evals（评测） + +你可以为特定任务跑轻量级的 eval：在 worktree 里派生几个独立的 agent，再派生比较 agent，对照一份评分标准去比对、给特定的输出打分。 + +比如，对照某个判据来评估、然后打磨你做的一个 skill。 + +### 模型与智能路由 + +造一个针对你的任务调过的分类 agent，让它来决定该用哪个模型。 + +当你的任务会涉及很多次 tool uses、而在执行前先做点研究如何能帮你认出最适合的模型时，会很有用。 + +举个例子，“解释一下 auth 模块是怎么工作的” 这个任务，最适合的模型取决于 auth 模块里有多少文件、以及代码库的形态。 + +一个分类 agent 可以先做这个研究，再根据任务的预期复杂度路由到 Sonnet 或 Opus。 + +--- + +## 什么时候别用动态工作流 + +Workflows 是新东西。虽然在很多场景里它能创造出格外好的效果，但并不是每个任务都需要它，而且它可能最终会用掉多得多的 token。 + +最好是创造性地用 workflows，把 Claude Code 推到你以前没推到过的地方。对常规的写代码任务，试着问问自己：这事真的需要更多算力吗？ + +比如，大多数传统的写代码任务，并不需要一个五人审查团。 + +--- + +## 搭建动态工作流的几个技巧 + +### Prompt 写法 + +用我们上面讲的那些具体技巧，可以把 prompt 写得细致，dynamic workflows 的效果最好。 + +但 Workflows 也不只为大任务准备。你可以提示模型用一个「quick workflow」。比如，对某个假设做一次快速的对抗式审查。 + +### 配合 /goal 和 /loop + +这块我想多聊两句，因为它正好解了我开头那个坑。 + +官方的用法是：可以重复跑的 workflow（分流、研究、核查这种），用 `/loop` 定时跑，再用 `/goal` 给它设一个硬性的完成要求。 + +但我更想说的是 /goal 和 workflow 的关系。/goal 管的是「一直干到完成别停」，可你要是只开 /goal、让一个脑子去扛一个几十小时的大目标，它就会像我那次一样，跑着跑着就飘了。workflow 管的是另一头：把活拆成一堆各自只盯着自己那一摊的小 agent。 + +这俩得搭着用。我那次 75 小时翻车，问题真不在 /goal，是我让一个脑子单扛了一个三天的目标。要是先用 workflow 把活拆开、再拿 /goal 去盯，goal 盯的东西就靠谱多了：一条拆开的、每步都能单独验证的流水线，而不是一个闷头干三天、最后还失忆的脑子。这个区别，我觉得是这次更新里对我最有用的一点。 + +### Token 用量预算 + +你可以为 dynamic workflows 设置明确的 token 用量预算，限制一个任务用掉多少 token。你可以用一个预算来提示它，比如「use 10k tokens」，这就会设上上限。 + +--- + +## 保存与分享动态工作流 + +你可以在 workflow 菜单里按「s」来保存 workflow。你可以把它们 check 进 `~/.claude/workflows`，或者通过一个 skill 来分发它们。 + +![image-20260605092534641](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260605092534641.png) + +要通过 skill 来分享，把你的 JavaScript workflow 文件放进 skill 文件夹，并在 `SKILL.md` 里引用它们。 + +为了留出更多灵活度，你可能想提示 Claude：把 skill 里的 workflow 当成一个模板，而不是一个必须逐字照跑的脚本。 + +![image-20260605092548716](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260605092548716.png) + +--- + +把这套东西扒到底，我的看法是：**dynamic workflows 最关键的地方，是把一个模糊的大任务，变成一件你能验证的工程。** + +它对抗的偷懒、偏袒、漂移，说的其实是一件事，**黑箱你没法验证**。一旦拆成一堆隔离的、各自带验证环节的小 agent，你至少知道每一步在干嘛，也知道哪一步能被另一个 agent 当场挑错。 + +所以它适不适合各位读者朋友们，我觉得有两种考量吧。 + +- 任务一句话能说完、十分钟能干完，别碰，单 agent 就够。 +- 任务长、杂、要反复验证，而且你被它跑着跑着就跑偏坑过，那它就是冲着你这个痛点来的。 + +我那个 75 小时的 goal，要是重来，我大概不会硬着头皮扛三天了。 + + + +本文图源：Thariq《A harness for every task: dynamic workflows in Claude Code》 + +文章参考：https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code diff --git "a/ai-articles/01-agent-and-coding/\344\273\212\345\244\251\346\210\221\347\232\204\347\233\256\346\240\207\345\260\261\346\230\257\357\274\214\346\210\221\350\246\201\346\212\212 QClaw \346\216\245\345\205\245\345\210\260\345\276\256\344\277\241\345\205\254\344\274\227\345\217\267\344\270\255\343\200\202.md" "b/ai-articles/01-agent-and-coding/\344\273\212\345\244\251\346\210\221\347\232\204\347\233\256\346\240\207\345\260\261\346\230\257\357\274\214\346\210\221\350\246\201\346\212\212 QClaw \346\216\245\345\205\245\345\210\260\345\276\256\344\277\241\345\205\254\344\274\227\345\217\267\344\270\255\343\200\202.md" new file mode 100644 index 0000000..8bd2517 --- /dev/null +++ "b/ai-articles/01-agent-and-coding/\344\273\212\345\244\251\346\210\221\347\232\204\347\233\256\346\240\207\345\260\261\346\230\257\357\274\214\346\210\221\350\246\201\346\212\212 QClaw \346\216\245\345\205\245\345\210\260\345\276\256\344\277\241\345\205\254\344\274\227\345\217\267\344\270\255\343\200\202.md" @@ -0,0 +1,497 @@ +# OpenClaw 接入微信公众号 + +> 日期：2026-03-23 + +[toc] + + + +其实如果你是这两天新关注的朋友，回复私信的时候应该已经发现了，现在公众号回复的内容已经不是冷冰冰的关键词链接了。 + + + +而是一个活泼调皮的小 AI 隐藏在公众号后面响应你的消息。 + + + +![](https://cdn.jsdelivr.net/gh/doggaifan/picbed/c65e98f3-8e63-416b-8b57-199af6fd3ac2.png) + + + +没错，**我把 OpenClaw 接入到微信公众号了。** + + + +就在昨天，微信发布了把 Clawbot（其实就是 OpenClaw） 接入到微信中的消息，一经发布，网上直接炸锅了。因为微信就是庞大的生态流量入口，微信生态会随着 Clawbot 的接入得到长久的发展。 + + + +我不得不说，微信接入 OpenClaw 的这个逻辑，跟我想的如出一辙，只不过他接入了微信中，而我是把 **OpenClaw 接入到微信公众号中**。 + + + +为什么要这么做？ + + + +用过 AI 助手的人都知道，最麻烦的不是 AI 本身，而是**入口**。 + + + +打开网页、登录账号、找到对话框……每次用都要这么多步骤，久而久之就懒得用了。 + + + +微信不一样。微信是我每天必开的 App，如果 AI 就在公众号里，随时发消息随时得到回复，使用频率会高很多。 + + + +但是微信公众号本身不能直接对接 AI，需要一个中间层做协议转换——把微信的 XML/JSON 消息格式转成 OpenAI 兼容格式，再把大模型的输出转回微信的消息格式，通过客服接口推回去。 + + + +这个中间层，是写了一个 Node.js 的一个小服务。 + + + +整个调用流程如下： + + + +``` +用户发消息 +↓ +微信公众平台云 +↓ +我的服务器（nginx + Node.js） +↓ +请求队列 +↓ +OpenClaw（AI 网关） +↓ +大模型生成回复 +↓ +通过微信「客服消息接口」主动推送(需要 access_token) +↓ +回复给用户 +``` + + + +由于我微信公众号认证之前，采用的都是 V1.0 同步的方式，因为微信公众号限制了**私信发消息必须 5s 内回复**，所以不得已只能回复。 + + + +如果你处理流程是：接收消息 → 调用大模型 → 返回结果，那 5 秒根本不够——大模型生成长回复动不动就十几秒。后果就是： + + + +* 请求超时 → 微信重试 → 又一次调用大模型 → 再超时 +* 用户收到重复回复，或者干脆收不到回复 +* 作者钱包受苦：重复调用浪费 token + + + +这体验，我是读者我直接取关。 + +![](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260322102933103.png) + + + +> 所以在认证通过之前，这个方案根本不可用。这也是为什么我一定要认证公众号的关键原因之一，拿到 AppSecret 才能用 V2.0 异步方案。 + + + +--- + + + +认证公众号拿到 AppSecret 之后，我们就可以走异步了： + + + +异步的**核心思想**：微信推送消息过来之后，立刻返回空成功应答（告诉微信"我收到了"），然后后台异步处理，处理完了再通过微信「客服消息接口」**主动推送**给用户。这样彻底避开 5 秒限制。 + + + +![](https://cdn.jsdelivr.net/gh/doggaifan/picbed/c38fffdb-c74d-437e-93ba-0eb9b4695ceb.png) + + + +关键流程代码大概是这样（简化版）： + + + +```js +// 微信公众号回调入口 +app.post('/wechat/callback', async (req, res) => { + const message = parseWechatMessage(req.body); + + // 关键点：立刻返回成功，释放连接 + res.status(200).send(''); + + // 异步丢进队列处理 + messageQueue.add(message); +}); +``` + + + +然后后台消费者处理： + + + +```js +async function processMessage(message) { + // 1. 速率限制检查 + if (!rateLimiter.check(message.fromUser)) { + await sendWechatMessage(message.fromUser, + "请求太频繁了，请1分钟后再试"); + return; + } + + // 2. 调用 OpenClaw 获取 AI 回复 + const aiReply = await openClaw.chat(message.content, message.fromUser); + + // 3. 通过客服接口推给用户 + await sendWechatMessage(message.fromUser, aiReply); +} +``` + + + +access_token 管理坑： + + + +![](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260322211855592.png) + +这也就是说，获取 access_token 的接口每天调用次数有限 + + + + - access_token 有效期 2 小时，过期需要刷新 + + + + - 如果多实例部署，必须全局共享一个 access_token + + + +所以这里我的做法是单例模式维护 + 定时自动刷新： + + + +```js +class WechatTokenManager { + private accessToken: string = ''; + private expireTime: number = 0; + + async getToken(): Promise { + // 如果没过期直接返回 + if (Date.now() < this.expireTime && this.accessToken) { + return this.accessToken; + } + + // 过期了重新获取 + const response = await fetch(`https://api.weixin.qq.com/cgi-bin/token?grant_type=client_credential&appid=${APPID}&secret=${APPSECRET}`); + const data = await response.json(); + + this.accessToken = data.access_token; + // 提前 5 分钟过期，防止临界问题 + this.expireTime = Date.now() + (data.expires_in - 300) * 1000; + + return this.accessToken; + } +} +``` + + + +这样保证任何时候拿到的都是有效 token，也不会频繁调用微信接口。 + + + +作为个人站点，资源有限，必须做好限流。我设计了两层限流： + + + +--- + + + +## 第一层：用户级速率限制 + + + + + +规则很简单： + + + + - 每个用户：1 分钟内最多 15 次请求 + - 超过限制直接回复："请求太频繁了，请1分钟后再试" + - 固定时间窗口（每分钟清零） + + + +实现用一个 Map 存用户计数，定时器定期清理： + + + +```js +class RateLimiter { + private userRequests = new Map(); + + check(userId: string): boolean { + const now = Date.now(); + const window = 60 * 1000; // 1分钟窗口 + + // 清理过期记录 + const requests = (this.userRequests.get(userId) || []) + .filter(time => now - time < window); + + if (requests.length >= 15) { + return false; + } + + requests.push(now); + this.userRequests.set(userId, requests); + return true; + } + + // 定期清理过期数据防止内存泄漏 + cleanup() { + const now = Date.now(); + const window = 60 * 1000; + for (const [userId, times] of this.userRequests) { + const valid = times.filter(t => now - t < window); + if (valid.length === 0) { + this.userRequests.delete(userId); + } else { + this.userRequests.set(userId, valid); + } + } + } +} +``` + + + +--- + + + +## 第二层：并发 + 队列控制 + + + +大模型推理耗资源，不能无限并发，所以做了如下处理： + + + +* 最多同时处理：32 个请求 +* 最多排队等待：100 个请求 +* 超出排队："当前排队人数较多，请稍后再试"。 + + + +用 Bull 或者 者 Node.js 自带的队列都可以实现，我这里用的是原生 Node.js 数组 + setImmediate 实现的简单队列。 + + + +```js +const requestQueue = []; +let currentConcurrent = 0; +function processNext() { + if (currentConcurrent < MAX_CONCURRENT && requestQueue.length > 0) { + const task = requestQueue.shift(); + currentConcurrent++; + process(task).finally(() => { + currentConcurrent--; + setImmediate(processNext); + }); + } +} +``` + + + +我觉得以我号目前的流量来说，没那么大，这个配置够用了。 + + + +![](https://cdn.jsdelivr.net/gh/doggaifan/picbed/11656222-8192-4b91-9e02-322572376f20.png) + +![](https://cdn.jsdelivr.net/gh/doggaifan/picbed/552415dd-32a4-4c4b-957b-247e70ddcf5d.png) + + + +--- + + + +## 多轮会话记忆怎么存？用户隔离怎么保证？ + + + +要让 AI 向人一样连续对话，必须保存上下文，我的做法是： + + + +* 以用户唯一的 OpenID 作为 Key 存储对话历史，不同用户完全隔离。 + +* 每个对话保留最近 N 轮（控制上下文长度，节约 token） + +* 超过 24 小时不活跃自动清理 + +* wechat-bridge 本地管理历史 + uniqueUser 参数 + + + +这样就保证了，你和 Clawra 的对话只有你能看到，绝对不会串到其他用户那里去。 + + + +现在这个公众号里有一个真正能对话的 AI，有记忆、有人格、能回答各种问题，还会关心你。 + + + +最重要的是——**入口变简单了**。 + + + +打开微信 → 找到「cxuanAI」→ 发消息 → 完事。 + + + +现在 cxuanAI 可以作为一个**智能体**来使用了。 + + + +b9babc8a-ebc0-4631-8b96-daf0ec39b0fa + + + +--- + + + +## 关于上下文限制 + + + +我实测了一下，在多轮对话中，保留上下文是让 AI 理解聊天历史的关键，但上下文长度不能无限制地增长——大模型有 Token 限制（一般在 4K-128K 之间），过长的对话历史会导致以下问题： + + + +* Token 超限：每个模型都有最大上下文长度（Context Window）。以我目前使用的 coding plan 为例： +* 输入限制：约 6K 字符（≈3K Token） +* 总限制：4K Token（包含用户输入+系统提示+历史） + + + +超过限制，接口直接返回 400 Total tokens of image and text exceed max message tokens。 + + + +1fa74aeb-ae73-4a28-8d8f-20a6c4e2da45 + + + +实现方案： + + + +我在 Node.js 中间层做了严格的上下文管理： + + + +```js +// 对话历史存储 +const userHistories = new Map(); // key: openid, value: Array<{role, content}> + +// 保留最近 8 轮（16条消息，user+assistant各8条） +const MAX_HISTORY_ROUNDS = 8; + +async function processMessage(fromUser, content) { + // 获取或初始化用户历史 + if (!userHistories.has(fromUser)) { + userHistories.set(fromUser, []); + } + + const history = userHistories.get(fromUser); + + // 加入当前轮对话 + history.push({ role: 'user', content: content }); + + // 裁剪历史（保留最近 N 轮） + if (history.length > 2 * MAX_HISTORY_ROUNDS) { + history.splice(0, history.length - 2 * MAX_HISTORY_ROUNDS); + } + + // 发送给大模型时的消息详情 + console.log(`发送给 OpenClaw: 用户${fromUser}，${history.length}条消息`); + + // 调用大模型... +} +``` + + + +**/new 命令的坑** + + + +最初 /new 命令只清理了本地 userHistories，但 OpenClaw/大模型还在内部缓存对话历史。导致发一句话还是 token 超限。 + + + +解决方案：每次调用 OpenClaw API 时，给 user 参数加时间戳后缀，完全绕过缓存： + + + +const uniqueUser = `${fromUser}_${Date.now()}`; + + + +现在使用 /new 可以重新清空会话窗口。 + + + +>注意：这里说的不是清空和公众号发私信的聊天窗口，而是清空 OpenClaw 的历史记录。由于公众号的限制，是无法像 /clear 这样清空聊天窗口信息的。 + + + +所以当你使用 /new 的时候，相当于就是重新开始了一个新的会话。 + + + + + +## 关于成本和使用提醒 + + + +目前 Clawra（就是这个 AI 妹子）用的大模型都是我自掏腰包买 token 给大家提供服务，所以： + + + +* 正常使用完全没问题，尽管来聊。 + +* 尽量不要发无意义的重复请求，节约 token 人人有责。 + +* 如果遇到限流问题，等一分钟就好。 + + + +本来是作为一个 18 岁甜美系的韩系小少女，但是配上这个头像现在看起来好像一个抠脚大汉在回复。。。。。。（别误会，其实我是大帅批） + + + +以后，Clawra 就是大家共同拥有的了，所以请好好善待她，你的每次使用都是在帮她成长。 + + + +最后，我制作了一个腾讯文档用于收集一下大家的意见，请留下您宝贵的回复。 diff --git "a/ai-articles/01-agent-and-coding/\344\273\216 IDE \345\210\260 CLI\357\274\214\345\206\215\345\210\260 Thread\357\274\232Codex \346\211\200\344\273\243\350\241\250\347\232\204\346\226\260\344\270\232\346\200\201\345\275\242\346\200\201.md" "b/ai-articles/01-agent-and-coding/\344\273\216 IDE \345\210\260 CLI\357\274\214\345\206\215\345\210\260 Thread\357\274\232Codex \346\211\200\344\273\243\350\241\250\347\232\204\346\226\260\344\270\232\346\200\201\345\275\242\346\200\201.md" new file mode 100644 index 0000000..42577cd --- /dev/null +++ "b/ai-articles/01-agent-and-coding/\344\273\216 IDE \345\210\260 CLI\357\274\214\345\206\215\345\210\260 Thread\357\274\232Codex \346\211\200\344\273\243\350\241\250\347\232\204\346\226\260\344\270\232\346\200\201\345\275\242\346\200\201.md" @@ -0,0 +1,121 @@ +# 当编程不再只是写代码：Codex 的 Thread，可能是一种新的软件生产界面 + +> 日期：2026-04-04 + +最近我开了一个 GPT pro 的年会员，用起来了 GPT-5.4 ，效果当然很不错，但我这篇想要跟你聊的不是模型测评能力。 + +而是另外一种新的东西。 + +当我想要在 CodeX 上找到 worktree 的时候，我发现没有，因为我还保持着 IDE 的思维模式，我以为像这种 GUI 的图形工具得有这么个东西。 + +但我错了，我全错了，这是一种思维定势。 + +很多人包括我都把它理解成 IDE 的增强版。编辑器里多了一个对话框，你写代码的时候它帮你补全、解释、重构，像一个更聪明的副驾驶。 + +另外一种是把它理解成 CLI 的升级版。你不再手敲那么多命令，而是直接告诉系统你要做什么，它替你在终端里执行、排查、修复。 + +但如果把 Codex 这类产品认真看一遍，会发现它指向的也许不是 IDE，也不是 CLI，而是第三种形态。 + +这种形态的关键字，不是“编辑器”，也不是“命令行”，而是 `Thread`。 + +image-20260404094243779 + +这不是一个小变化。它更像是软件生产界面的一次重组。 + +我们过去太习惯于把编程理解为一种“实时手工劳动”：打开 IDE，定位文件，修改代码，切到终端，跑测试，回来看报错，再改一轮。整个过程里，人的注意力被牢牢绑定在一个同步、连续、即时响应的工作流里。IDE 也好，CLI 也好，本质上都服务于这种模式。 + + + +image-20260404094600252 + +image-20260404094521035 + +但 Thread 的逻辑不同。 + +在 Thread 里，最小工作单位不再是“我正在改哪一个文件”，也不是“我马上要执行哪一条命令”，而是“我要推进哪一件事”。你开一个新的 thread，不一定意味着立刻写代码，也可能是让系统先去读仓库、理解上下文、排查 bug、起草方案、并行尝试几条路径，最后再把结果带回来给你审阅。 + +--- + +这背后隐含的是一次角色转换。 + +开发者不再只是那个亲手完成每一步操作的人，而开始更像一个任务发起者、协调者和验收者。你仍然写代码，仍然做判断，仍然承担责任，但你和工具的关系，已经从使用工具慢慢变成调度能力。 + +这就是 Codex 的 Thread 形态真正值得讨论的地方。 + +它区分于传统 IDE，不是因为界面长得不一样，而是因为它不再把文件编辑当作核心。它也不同于 CLI，不是因为它更易用，而是因为它不再把命令执行当作核心。它试图把软件开发里的核心单元，从文件和命令，提升为任务和上下文。 + +这听起来像是一个抽象变化，但它可能非常实际。 + +因为真实的软件开发，本来就不是按文件组织的，而是按问题组织的。一个 bug、一张工单、一个需求、一段用户反馈、一场线上事故，这些才是团队真正围绕其运转的对象。文件只是承载，命令只是手段，任务才是生产的真实单位。 + +从这个意义上说，Thread 并不是给 IDE 加了层聊天皮肤，而是试图把软件工作真正围绕什么展开这件事，重新显式化。 + +这也是为什么，越来越多 AI 编程产品看起来像聊天，实际上却不是为了聊天。它们真正想做的，是把对话变成任务容器，把上下文变成可持续资产，把执行过程变成可回看的轨迹。 + +人们表面上看到的是一个新 thread，底层发生的却是另一种工作组织方式的成型。 + +如果把 IDE 看作是代码的衍生，把 CLI 看作执行的衍生，那么 Thread 更像是任务的衍生。 + +而任务衍生一旦成立，很多以前割裂的动作就会被重新串起来。 + +需求理解、仓库探索、方案推演、代码生成、测试执行、结果回收、审查反馈，这些本来分散在多个工具里的环节，会被一个 thread 统一承载。你不再只是在一个工具里完成一部分工作，而是在一个 thread 中持续推进一件事。 + +这恰恰是它最像**新业态**的地方。 + +因为所谓新业态，从来不只是一个新功能，而是一个新的组织单位。 + +电商不是把商店搬到网上，而是把交易流程重组了；短视频不是把视频变短，而是把内容分发逻辑重组了。类似地，Thread 也不是把聊天嵌入开发，而是在重组软件生产的操作界面。 + +--- + +那么，这种形态可持续吗？ + +我认识是的。但它的可持续，不会表现为 Thread 取代 IDE 或者 Thread 杀死 CLI ，而是表现为它成为这两者之上的一个新入口。 + +原因很简单。IDE 和 CLI 解决的，仍然是不可替代的问题。IDE 提供的是高带宽的阅读、编辑和局部调试能力；CLI 提供的是最直接、最快速、最可控的本地执行能力。这两种能力都不会消失。你要精细修改一个复杂函数，还是要回到代码；你要临时看一条日志、跑一条命令，还是终端最快。 + +但 Thread 解决的是另一类问题：任务如何被发起，如何被拆解，如何被并行推进，如何保留上下文，如何在中断之后继续，如何把结果带回给人类决策。 + +而这类问题，在 AI 时代会越来越重要。 + +因为一旦代理能力变强，开发中的稀缺资源就不再只是会不会写代码，而是能不能把复杂工作组织起来。一个人一天能亲手完成的步骤是有限的，但他能同时推进多少条 thread，却可能远远超过过去。真正拉开差距的，不再只是编码速度，而是任务管理能力、上下文管理能力、审阅能力和风险控制能力。 + +从这个角度看，Thread 不是多余的一层，它反而可能是 AI 编程真正成熟之后最需要的一层。 + +--- + +当然，它也不是没有问题。 + +第一，Thread 很容易造成新的管理负担。以前大家抱怨 IDE 标签页太多、终端历史太乱，未来很可能会抱怨 thread 太多、上下文太碎、任务边界太模糊。 +第二，Thread 对任务描述质量有要求。问题说不清，代理就容易跑偏；目标不稳定，thread 很快变成噪音。 +第三，Thread 会把人的工作重心从亲手操作转向结果审查，这意味着 review 机制、可解释性和回溯能力会变得比过去更关键。 +第四，它不适合所有场景。很多即时、小颗粒、试探性的动作，仍然更适合在 IDE 或 CLI 里直接完成，而不是单独开一个 thread。 + +所以更准确地说，Thread 的未来不是通吃，而是**分层**。 + +未来的软件开发，很可能会形成一个更加清晰的三层结构。 +底层是 CLI，负责最原始、最确定的执行。 +中层是 IDE，负责人类高带宽地理解和修改代码。 +上层是 Thread，负责任务编排、代理协作、上下文延续和结果回收。 + +这三者并存，才是更现实的图景。 + +--- + +也正因为如此，Codex 这类产品真正值得关注的，不是它能不能再多写几段代码，而是它是否在定义一种新的软件生产界面。它试图回答的问题不是怎么让 AI 更像一个补全工具，而是当 AI 可以持续工作、并行工作、接手子任务时，人类该如何组织它。 + +这个问题一旦成立，Thread 就不是一个临时交互形式，而是一种长期存在的工作容器。 + +它像一个新的桌面，不只是一个新的窗口。 +它像一个新的生产单元，不只是一个新的功能按钮。 +它甚至有点像软件开发进入 agent 时代后的标签页制度，以前一个标签页对应一个文件，未来一个 thread 对应一件正在推进的事。 + +如果说 IDE 代表的是代码时代的主界面，CLI 代表的是系统时代的主界面，那么 Thread 很可能代表的是代理协作时代的主界面。 + +这也是 Codex New Thread 最值得重视的地方。 + +它不只是把编程变得更自动，而是在悄悄改变一个更深层的问题：软件开发究竟应该围绕什么来组织。过去的答案是文件、函数、命令；现在，一个新的答案正在出现，那就是任务、上下文和线程。 + +而一旦这种组织方式被用户习惯、被团队接受、被流程吸收，它就很难再退回去。 + +这或许就是所谓新业态真正成熟的标志。不是它看上去多新，而是人一旦用过，就会开始觉得旧方法不够用了。 diff --git "a/ai-articles/01-agent-and-coding/\345\244\252\351\241\266\344\272\206\357\274\214ChatGPT \350\246\201\345\222\214 Codex \346\220\236\344\270\200\350\265\267\344\272\206\343\200\202.md" "b/ai-articles/01-agent-and-coding/\345\244\252\351\241\266\344\272\206\357\274\214ChatGPT \350\246\201\345\222\214 Codex \346\220\236\344\270\200\350\265\267\344\272\206\343\200\202.md" new file mode 100644 index 0000000..5f0aae8 --- /dev/null +++ "b/ai-articles/01-agent-and-coding/\345\244\252\351\241\266\344\272\206\357\274\214ChatGPT \350\246\201\345\222\214 Codex \346\220\236\344\270\200\350\265\267\344\272\206\343\200\202.md" @@ -0,0 +1,264 @@ +# 太顶了，ChatGPT 要和 Codex 搞一起了。 + +> 日期：2026-06-03 + + +![image-20260603081702030](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260603081702030.png) + +*图源：OpenAI 官方资料，searchnews 制图* + +2026 年 6 月 2 日，OpenAI 开了一场直播：`Intelligence at Work`。 + +我一直以为时间是今天早上八点半，结果。。。。。。完美错过，所以只能看了重播。 + +我把整场发布会看完了，这场发布会，不是又多了几个办公插件这种小众事件。 + +真正的变化是：**OpenAI 正在把 ChatGPT 变成入口，把 Codex 变成执行层。** + +>说白了，OpenAI 要把 ChatGPT 和 Codex 直接整合。 + +![image-20260603083548103](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260603083548103.png) + +我说怎么昨天 Tibo 发了一条消息，说**我们应该吧 Codex 改名为 ChadGPT 吗**，看起来像是面向大家来调研，实则是向大家汇报。。。 + +image-20260603083332441 + +以前你问 ChatGPT，它给你答案。现在 OpenAI 想让你在 ChatGPT 里交代一件事，然后让 Codex 在背后查文件、跑工具、写代码、做页面、改 PPT，最后拿出一个能交付的东西。 + +--- + +看完发布会，让我印象最深的一个点是，Codex 不再只属于程序员了。 + +Codex 最早的标签很清楚：写代码。 + +2025 年 5 月，OpenAI 发布 Codex 时，官方定义是一个云端软件工程 Agent。它能在独立 sandbox 里读代码、改文件、跑测试、提交补丁。对程序员来说，这是一个很强的异步同事。 + +但一年后，OpenAI 发现了一件事。 + +Codex 的用户不只是在写代码。 + +官方这次给了几个数：Codex 周活已经超过 500 万；非开发者大约占 20%；这一群人的增长速度，比开发者还快 3 倍以上。 + +![image-20260603081928004](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260603081928004.png) + +*图源：OpenAI 官方资料，searchnews 制图* + +这就解释了为什么 OpenAI 要做这次整合。 + +如果 Codex 只是一个开发者工具，它可以继续待在自己的 App、CLI、IDE 里。 + +但如果 Codex 开始帮市场团队做 launch kit，帮销售团队写客户跟进，帮财务团队整理月结材料，帮运营团队做流程审计，它就不能只待在程序员入口里。 + +它必须进入 ChatGPT。 + +因为企业里真正普及的入口，是 ChatGPT。 + +--- + +## ChatGPT 负责入口，Codex 负责跑完 + +但是！！OpenAI 这次不是简单合并两个 App，而是在拆角色。 + +ChatGPT 负责降低使用门槛。 + +Codex 负责把事情推进到可交付。 + +![image-20260603081943620](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260603081943620.png) + +*图源：OpenAI 官方资料，searchnews 制图* + +企业员工不一定知道什么时候该打开 Codex。很多人甚至不知道 Codex 能干什么。 + +但他们知道 ChatGPT。 + +所以 OpenAI 的选择很直接：大家不用判断工具入口了，我直接给大家装一块了。 + +用户不想在手机和电脑上装几十个 AI 工具。真正会留下来的产品，不一定是能力最全的产品，而是用起来最顺手的产品。 + +这句话放在 OpenAI 身上，就是 ChatGPT。 + +**这，就是 Super App** + +放在 Codex 身上，就是从你去找它变成它就在 ChatGPT 里面等你。 + +你品，你细品，这极强的情绪价值。 + +--- + +## 三个新功能，其实是一条 workflow + +这次 OpenAI 给 Codex 发了三件东西：Agent Plugins、Annotations、Sites。 + +这三个玩意，听起来像三个功能点。 + +但把它们捏合在一起看，它们其实是一条完整工作流。 + +插件解决「我能连什么工具」。 + +Annotations 解决「我怎么局部修改」。 + +Sites 解决「我怎么把产出分享给团队」。 + +![image-20260603082155826](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260603082155826.png) + +*图源：OpenAI 官方资料，searchnews 制图* + +先说插件。 + +OpenAI 这次推出 6 个角色插件，覆盖数据分析、创意制作、销售、产品设计、公开市场投资、投行。官方说，这些插件合计接入 62 个常用应用，打包 110 项 skills。 + +这不是传统意义上的 `skills marketplace` 。 + +这 TM 的是岗位工作技能包。 + +大家可以想一下，你为什么能胜任这项工作，是不是因为你具备了这项工作所必备的技能？ + +比如数据分析插件，不只是让 Codex 连 Snowflake 或 Tableau。它要理解业务问题，查数据，解释指标变化，再做成报告和 dashboard。 + +创意制作插件也不是简单生成图片。它要从 brief 出发，做 mood board，出广告图，接到 Figma、Canva 这类工具里继续改。 + +![image-20260603083821590](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260603083821590.png) + +销售插件则接 CRM、Slack、HubSpot 这类系统，帮团队找高优先级账户、准备客户会议、写 follow-up、更新客户记录。 + +这就比「AI 帮我写一段文案」更接近真实工作。 + +真实工作从来不是一句 prompt 结束。 + +真实工作是拿上下文、调工具、产出初稿、被人修改、再放进团队流程里。 + +看完我只想说，失业越来越快了。 + +--- + + +很多 Agent 产品有一个共同问题：第一版看着很厉害，但改起来很痛苦。 + +这个我是深有体会。 + +你让它做一份报告，报告 80% 都对，但有一个图表不顺眼，后续你就得为了一个不顺眼的图表搭上至少 2 倍的时间。 + +我相信各位读者朋友们也是深有体会，这最后一公里的成本，要比前面所有公里的成本加起来还多。 + +Annotations 做的就是这件小事：你指哪，它改哪。 + +OpenAI 的官方说法是，开发者已经用 annotations 来改代码、Markdown 文件和网站。 + +现在这套方式扩展到了文档、表格和幻灯片。 + +![image-20260603083648843](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260603083648843.png) + +在办公的 workflow 里，大多数时间不是从 0 到 1，而是从 80 分改到 90 分。 + +你选中 slide 上的图表，让 Codex 换一个更清晰的标签。你标出投资报告里一句结论，让它补来源。你圈住网页导航栏，让它换字体。 + +它只动被你圈住的地方。 + +这才像人和 Agent 共同在协作。 + +--- + +## Sites 把产物变成一个活页面 + +我觉得这次最有想象力的功能，是 Sites。 + +OpenAI 的官方描述是：Codex 可以把想法、分析和计划变成交互式、托管的网页或 App，并通过 URL 分享给 workspace 里的同事。 + +这个想法太 exciting 了。。。 + +目前 Sites 是 Business 和 Enterprise 客户的 preview，主要面向 workspace 内部分享。 + +![image-20260603082214134](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260603082214134.png) + +*图源：OpenAI 官方资料，searchnews 制图* + +这件事看起来像「一句话生成网站」，但我觉得更准确的理解是：**OpenAI 想扩展文档、表格、PPT 之外的交付模式。** + +> 这很像 Claude Code 的 Tariq 发的 HTML 要比 MarkDown 更适合成为交付工具。 + +很多工作本来就不适合塞进 PPT。 + +财务预测更适合变成 scenario planner。 + +产品发布更适合变成一个随时更新的 launch hub。 + +客户 review 更适合变成一个能点、能看趋势、能记录问题的内部页面。 + +--- + + +这类发布会很容易被写成万能 Agent，然后大家又激动起来，导致 OpenAI 市值又飙升的戏码。 + +但有三个问题需要注意。 + +![image-20260603082229962](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260603082229962.png) + +*图源：OpenAI 官方资料，searchnews 制图* + +Codex 没有消失。 + +更准确的说法是，Codex 能力会进入 ChatGPT，独立的 Codex 入口依然存在。开发者仍然会在 App、CLI、IDE、GitHub 这些地方使用它。 + +权限也没有自动放开。 + +OpenAI Help Center 写得很清楚，Business、Enterprise、Edu workspace 里的插件访问，会跟随 workspace app controls。 + +管理员可以在工作区设置里禁用对应 App，也能通过 RBAC 控制谁能访问。 + +ChatGPT 和 Codex 的对话也不是完全混在一起。 + +官方帮助文档提到，两边 conversations 仍然分开，但一些设置和已连接服务可能会沿用。 + +比如你在 ChatGPT 里接了 Google Drive，Codex 里也可能可用；你也可以随时断开。 + +Agent 真要进入工作流，比拼的不是 demo 有多顺，而是权限、审计、上下文、确认机制能不能顶得住。 + +--- + +所以，这次 Codex 和 ChatGPT 整合，不能只看成一个产品更新。 + +它更像 OpenAI 在抢工作层。 + +模型越来越强之后，用户不会每天比较 benchmark。 + +用户会问更朴素的问题： + +这东西能不能拿到我的上下文？ + +能不能替我跑工具？ + +能不能把结果做成可交付物？ + +能不能让我局部改，而不是推倒重来，浪费时间？ + +能不能放到团队里共享、追踪、复用？ + +谁能把这几个问题回答好，谁就更接近企业 AI 的默认入口。 + +Claude Code 在开发者心里很强，微软 Copilot 占着 Windows 和 Office，国内的飞书、钉钉也都在往统一入口里塞 Agent。 + +OpenAI 的优势，是 ChatGPT 已经站在了太多人每天打开的地方。 + +Codex 这次往 ChatGPT 里走，本质上是在把「会执行」变成默认能力。 + +因为默认入口一旦成立，用户甚至不会意识到自己在切换工具。 + +他只会觉得：我刚刚让 ChatGPT 把这件事做完了。 + +这才是我认为 OpenAI 真正想要的东西。 + +它不只是让你多认识一个 Codex。 + +它更想让你忘记自己还需要单独打开 Codex。 + +--- + +资料来源： + +- OpenAI：《[Intelligence at Work: an OpenAI livestream](https://openai.com/business/intelligence-at-work/)》 +- OpenAI：《[Codex for every role, tool, and workflow](https://openai.com/index/codex-for-every-role-tool-workflow/)》 +- OpenAI：《[Introducing workspace agents in ChatGPT](https://openai.com/index/introducing-workspace-agents-in-chatgpt//)》 +- OpenAI：《[Introducing Codex](https://openai.com/index/introducing-codex/?video=1084810944)》 +- OpenAI Academy：《[How to use Codex for everyday work](https://openai.com/academy/how-to-use-codex-for-everyday-work/)》 +- OpenAI Help Center：《[Using Codex with your ChatGPT plan](https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan)》 +- 9to5Mac：《[OpenAI putting Codex inside ChatGPT app everywhere](https://9to5mac.com/2026/06/02/openai-putting-codex-inside-chatgpt-app-everywhere-releasing-6-business-plugins/)》 diff --git "a/ai-articles/01-agent-and-coding/\345\246\202\344\275\225\346\212\212 Codex \347\224\250\345\210\260\346\236\201\350\207\264.md" "b/ai-articles/01-agent-and-coding/\345\246\202\344\275\225\346\212\212 Codex \347\224\250\345\210\260\346\236\201\350\207\264.md" new file mode 100644 index 0000000..1840a18 --- /dev/null +++ "b/ai-articles/01-agent-and-coding/\345\246\202\344\275\225\346\212\212 Codex \347\224\250\345\210\260\346\236\201\350\207\264.md" @@ -0,0 +1,264 @@ +# 如何把 Codex 用到极致 + +大多数开发者第一次用编程 agent 都是为了写代码：检查一个仓库、生成一份 diff、跑测试、开一个 pull request。 + +这至今仍是 Codex 的重心。但电脑上的很多工作本来就以代码为中介：执行 shell 命令、浏览网页、调用 API、导出文档、响应事件、触发自动化。当这些界面逐一向 Codex 开放，它给人的感觉就不再是狭义上的编程助手，而更像一套用来完成电脑上各种工作的系统。 + +Codex 应用把这个转变落到了实处。一个线程（thread）能保留上下文、使用工具、呈现产物（artifacts），并跨多轮 prompt 持续下去，而不是每次交互结束后就重置。 + +想从 Codex 身上得到更多，就要把这些能力组合起来用： + +- 持久线程（durable threads），保留上下文 +- 语音、操控（steering）、排队（queuing），让用户始终留在回路里 +- 浏览器、computer-use、MCP server 和 connector，让 Codex 在仓库之外也能动作 +- 线程自动化（thread automations）和目标（Goals），在用户离开时继续推进工作 +- 侧边栏（side panel），用户在那里审阅代码、文档、幻灯片和其他产物 + +--- + +## 持久线程 + +> 持久线程：长期运行的 Codex 线程，能跨多次会话保留工作上下文。 + +置顶线程（pinned threads）是把持久线程放在手边的一种方式。它适合反复出现的工作流，比如： + +- 一个参谋长（Chief of Staff）线程（相当于是 Thread 的大脑） +- 一个发布线程 +- 一个文档评审线程 +- 一个专门做外部监控的线程 + +这些是持久的工作区，不是简短的聊天。Codex 可以随时间反复回到这些线程里，保留此前的决定、偏好和工作上下文——否则这些东西就得从头重建。 + +置顶线程的快捷键让这件事变得实用。Command-1 到 Command-9 能直接跳进已保存的线程。 + +>这个确实很有用，因为用 AI 开发久了，我会发现很多时候同一个任务会散落在不同的 Thread 中，这个操作步骤相当于是把 Thread 变成了“角色”。 + +--- + +## 语音输入 + +语音输入的价值在于，它能在一个想法被压缩成打磨过的文字之前，捕捉到它粗糙的版本。 + +Codex 内置了语音输入。对于那些说出来很自然、打字却很别扭的模糊起点，它尤其好用： + +> 我记得有个叫 Ben 的人在 Slack 里提过这件事。 +> 具体细节我不记得了。 +> 你去查一下。 + +对一个能搜索、能收集上下文、能回来汇报的 agent 来说，这通常就够了。 + +在任务还没完全成形时，花两三分钟把想法一股脑倒出来，它也很合适。 + +转录文本同理。一份原始的会议转录，或者口述的计划笔记，往往比一段简短的摘要提供更好的素材，因为它保留了不确定、强调，以及没说完的思路。 + +--- + +## 操控与排队 + +当语音和对一个进行中任务的明确控制配合起来，它会变得更有用。 + +> 操控（Steering）：在当前步骤结束之前，用新的方向打断一个正在执行的 Codex 任务。 + +当 agent 走错了方向、需要在它做完之前纠正时，操控就有用。比如在评审一个网站时，用户可以一边在侧边栏标注界面，一边打断它的工作： + +- 把这个改小一点 +- 这两个元素之间的间距感觉不对 +- 这句文案是错的 + +> 排队（Queuing）：添加一些让 Codex 在当前步骤完成之后再做的工作。 + +排队不一样。它不打断进行中的任务，而是把下一个任务排进队列。用户可能会说： + +> 等这件事做完，把预览链接在 Slack 里发给评审的人。 + +操控改变 Codex 此刻正在做的事，排队改变接下来该发生的事。两者都让用户在工作展开的过程中始终贴近它。 + +>Steering 也非常有用，我目前经常用到 Steering 的地方是使用 goal 的时候定期让他出执行计划，判断与预期是否相符，是否有漂移等。 + +--- + +## 工具与触达范围 + +一旦一个线程具备了连续性，下一个问题就是：它能作用于什么。Codex 可以一层层地向外延伸： + +- `$browser`，对应侧边栏里的应用内浏览器，Codex 在那里可以检查和标注网页界面 +- `@chrome`，对应已登录的浏览器状态，以及基于 Chrome 的工作流 +- `@computer`，对应那些只存在于桌面图形界面（GUI）中的工作 + +`$browser` 适合在侧边栏里做浏览器评审。`@chrome` 适合那些依赖用户 Chrome 上下文、需要登录态的浏览器工作。`@computer` 适合那些只能通过桌面 GUI 完成的任务。 + +MCP server 和 connector 把同样的思路延伸到工作流的其余部分。 + +Slack、Gmail 和 Calendar 之所以重要，是因为很多重要的任务一开始是以消息、收件箱条目或排期问题的形式出现的，之后才变成代码。 + +Skills 让重复的工作流可以复用。一个工作流一旦被证明有用，就把它打包成一个 skill，这样 Codex 下次能再跑一遍，而不用从零重新学习这套流程。 + +--- + +## 随处都能工作 + +Codex 移动版改变了「用户必须坐在工位前」这件事。一个任务可以在 Mac 上启动——文件、权限和本地配置都已经在那里——然后在用户用手机查看时继续推进。 + +这在一些细小的时刻很重要。一个人可以在 Codex 跑一个较长的任务时离开工位，在外面回答一个问题、批准下一个步骤，或者在回到座位之前给线程换个方向。本地环境留在原处，而用户不必。 + +--- + +## Automation + +自动化按计划执行 Codex 的工作。如果一个重复性任务应该每次从一个工作区全新开始——比如一份日报，或者一次定期的仓库检查——就用定时自动化（scheduled automation）。如果这个计划应该回到一个带着运行上下文的活跃对话里，就用线程自动化（thread automation）。 + +> 线程自动化：心跳式的、周期性的唤醒，按计划回到同一个 Codex 线程。 + +置顶线程很有用，但它们仍然在等用户回来。线程自动化可以每隔几分钟或几小时检查一次某件事，持续下去直到满足某个条件，并随时间调整节奏。 + +一个参谋长线程可能每 30 分钟跑一次： + +> 每 30 分钟，检查 Slack 和 Gmail 里那些需要我关注、还没回复的消息。 +> 帮我把最重要的事排出优先级。 +> 如果有人问我问题，尽可能深入地研究答案，并替我起草一份回复，但不要发出去。 + +当用户回来时，收集上下文这个最昂贵的部分往往已经做完了。发出什么，仍然由人来决定。 + +线程自动化也适合反馈循环。一个线程自动化可以盯着 pull request 的评论、Google Docs 的评论或 Slack 的回复，在用户离开时让周边的工作继续往前。 + +设想一个动画制作的工作流：评审的人在 Slack 里分享了一段视频。一个线程自动化可以按计划检查这个会话，在评论到来时渲染出一个更新的版本，并在同一个会话里 @ 那位评审者回复。如果某个集成无法完成最后的上传，桌面自动化可以通过 GUI 把这一步做完。 + +这个循环横跨三处：用 Slack 收反馈、用代码库做渲染、用桌面自动化完成最后的上传。 + +>automation 对我的日常来说也很重要，不过这就相当于是个定时任务，这个大家应该都熟知了。 + +--- + +## /goal + +当一个任务有一条真实的终点线、agent 能持续朝它推进时，目标（Goals）最为强大。一个弱的目标是这样的： + +> 目标：运行时间更长的 Codex 任务，带有一条终点线，agent 能长期朝它持续工作。 + +> 把这个 Markdown 文件里的计划实现出来。 + +一个更强的目标有一条可度量的成功标准。 + +举个例子，一个工程师可能要把一个内部工具从 Python 迁移到 Rust：建好新目录，定义好目标，并把终点线写明确——新实现在单元测试通过之前都不算完成。 + +一个目标把持续的执行和一个验证器（verifier）结合在一起。用户定义结果、停止条件，以及那个能说明 Codex 是否在靠近终点的信号。 + +有用的验证器包括： + +- 一个测试套件 +- 一个 benchmark +- 一次 bug 复现 +- 一个验证矩阵 +- 一个必须一直保持通过的端到端工作流 + +有野心很重要，但没有验证，它就只是一个愿望。 + +>jason 这篇对于 /goal 的作用跟我和大家的预期几乎一致，AI 可以帮你连续做完所有的工作，但你要得保证他不漂移。 + +--- + +## 侧边栏 + +侧边栏把工作成果留在产生它的那个对话旁边。用户不必导出一个产物再切换上下文，而是可以就地审阅它。产出可能是代码，但也可能是一份幻灯片、一个 PDF、一个浏览器页面、一张表格，或者过程中产生的其他产物。 + +它尤其擅长四件事： + +1. 检查产物 +2. 标注哪里需要改 +3. 操作网页界面 +4. 评审改动 + +侧边栏让用户可以就地审阅 Markdown、电子表格、数据表、文档和幻灯片。他们可以检查、标注、修改这些产物，而不打断整个回路。 + +![image-20260528225123982](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260528225123982.png) + +那份幻灯片或 PDF 可以一直开在产生它的线程旁边，随时可以直接审阅和修补。 + +![image-20260528225140304](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260528225140304.png) + +应用内浏览器让 Codex 可以检查一个渲染好的页面、控制它，并直接在被审阅的界面上响应标注。对一个页面或产物的评论留在工作回路内部，而不是变成一次单独的交接。 + +网页同时成为输出和控制界面。Codex 可以构建一个产物，在侧边栏里打开它，检查它、调试它，并就地不断打磨同一个对象。 + +![image-20260528225157527](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260528225157527.png) + +下面这些载体尤其合适： + +- `index.html`，用于轻量的静态产物 +- Storybook，用于 UI 评审 +- Remotion Studio，用于程序化的动画 +- 基于浏览器的幻灯片，用于演示 +- 数据应用（data apps），用于分析类工作流 + +单单一个 index.html 文件，不需要服务器，就能成为一个持久的、可交互的产物。线程自动化还可以随时间刷新这些静态产物，这样当用户回来时，线程里已经有新的东西在等着。 + +--- + +## 共享记忆 + +当长期运行的线程能共享一份位于任何单个对话之外的记忆时，它们会变得更有用。 + +> 共享记忆：存储在单个线程之外的持久上下文，让未来的工作可以从一个明确、可审阅的东西接着做下去。 + +一个经得起时间的做法，是把持久线程锚定在一个 Obsidian vault 里。实际操作上，这意味着一个由纯文本文件组成的文件夹，它始终便于检查、编辑、移动，也便于长期保存。团队可以把这个文件夹放进云存储、Git、Dropbox、Google Drive，或者其他适合自己工作流的同步层。 + +一个 vault 大致可能长这样： + +``` +vault/ +├── TODO.md +├── people/ +├── projects/ +├── agent/ +└── notes/ +``` + +在顶层，`AGENTS.md` 可以定义：当 Codex 对人、项目、决定和未了结的事情了解得更多时，它应该如何更新这个工作区。 + +不要照搬某一个确切的 vault 结构。要教会 agent：持久上下文应该住在哪里、应该保留哪些上下文，以及什么时候不要制造无谓的变动。 + +一份实用的 `AGENTS.md` 可能会写： + +- 把 `~/vault` 当作持久的工作记忆。 +- 宁可要规范的笔记，也不要笔记到处蔓延。 +- 明确地把 TODO、人、项目、每日小结和草稿笔记各自归位。 +- 保留决定、阻塞项、负责人、日期和有用的链接。 +- 如果没有发生有意义的变化，就不要去搅动这个 vault。 + +代码仓库装的是代码。vault 装的是滚动的上下文：涉及的人、变了什么、卡在哪里、需要跟进什么，以及那些否则会在一次次会话之间消失的东西。 + +重要的上下文不该只活在一份对话记录里。把它写在某个下一个线程能接着读下去的地方。 + +Codex 自己也有第一方的记忆功能，在 `Settings > Personalization > Memories` 里。它们为偏好、重复出现的工作流和已知的坑提供了一个本地的回忆层。它们是对显式写下来的上下文的补充，而不是替代。Chronicle 朝同一个方向使力——它帮助 Codex 从最近的屏幕上下文中构建记忆。 + +## 从代码向外 + +Codex 仍然从代码出发。但代码周围的更多工作，现在可以通过同一套系统触达：MCP server、浏览器界面、桌面控制、线程自动化，以及可审阅的产物。 + +这改变了控制模型。操控打断进行中的工作。排队把下一个任务排好队。线程自动化在用户走开时让一个线程保持活跃。目标则加上一条具体的终点线，让 Codex 能持续朝它工作。 + +现在，Codex 能把一个工作流从指令、到执行、再到产物评审完整地承载下来——哪怕这项工作已经离开了代码仓库。 + +--- + +## 我的想法 + +这篇介绍的很多功能我觉得非常实用。 + +老模型是一个 prompt 换一个 diff，agent 是你调用的一个函数。新模型是一个持久线程，你像带一个同事那样带它。steering 是当面打断，queuing 是交代下一件事，automation 是它自己按点干活，goal 是给它一份验收标准。文章列的那一长串，本质是一套管理下属的原语。 + +而且一个非常具有可品味性的在于 /goal 那一节，goal 没有验证，你的蓝图只是个愿望。这句不只对 Codex 成立。 + +Agent 落地的真问题不在能力，能力早就够了，缺的是一个能回答它有没有做对的东西。Python 迁 Rust 那个例子好就好在终点线可执行——单测通过，而不是感觉差不多。我自己的基本和文章的一致：给不出验证的任务，agent 的产出基本不能直接用。 + +但最承重的一节是共享记忆，它却被排在很靠后的位置。前面那一串能力，底色都是让一个线程能长期接着干；可只要上下文还只活在对话记录里，所谓长期就是假的——线程一长照样丢。 + +真正让线程持久的是那个 vault：一个纯文本文件夹，加一个 `AGENTS.md` 教 agent 怎么维护它。注意 AGENTS.md 里那条没有实质变化就别搅动 vault。 + +最后一点：vault 这个模式不是 OpenAI 独有的。Claude Code 有 `CLAUDE.md`，各家 agent 各自摸索，最后都收敛到同一件事——agent 的记忆就是仓库里的纯文本文件，能看，能改，有 version control 。agent 要变成能长期托付的东西，靠的不是模型多强，是它有没有一块外部记忆。 + +功能 OpenAI 会一直加，但那块持久的、纯文本的、你自己也在维护的记忆，得你自己搭了来维护。 + +--- + +*原文：Jason Liu（@jxnlco）《Getting the most out of Codex》，2026-05-20 发布于 X（长文形式）。推文链接：https://x.com/jxnlco/status/2057153744630890620* diff --git "a/ai-articles/01-agent-and-coding/\345\246\202\344\275\225\347\224\25010\344\270\252Claude\345\267\245\344\275\234\346\265\201\347\250\213\346\257\217\346\234\210\350\212\202\347\234\20145\345\260\217\346\227\266.md" "b/ai-articles/01-agent-and-coding/\345\246\202\344\275\225\347\224\25010\344\270\252Claude\345\267\245\344\275\234\346\265\201\347\250\213\346\257\217\346\234\210\350\212\202\347\234\20145\345\260\217\346\227\266.md" new file mode 100644 index 0000000..ccf8978 --- /dev/null +++ "b/ai-articles/01-agent-and-coding/\345\246\202\344\275\225\347\224\25010\344\270\252Claude\345\267\245\344\275\234\346\265\201\347\250\213\346\257\217\346\234\210\350\212\202\347\234\20145\345\260\217\346\227\266.md" @@ -0,0 +1,566 @@ +# 10 个贼爽的 workflow 工作流 + +> 日期：2026-04-14 + +## 引言：时间都去哪儿了？ + +每个月，你有大约45个小时凭空消失了。 + +不是被什么大事吞噬——没有紧急危机，没有重大决策，只是那些零碎的、重复的、本可以自动完成的工作。它们像沙漏里的细沙，一粒粒漏掉，等你回过神来，一个月又过去了。 + +这就是我看到 Zodchiii 的数据时的第一反应。他用两周时间追踪了自己使用 Claude 的每一个瞬间：时间戳、任务类型、手动 vs AI 处理时间。结果很直接——**每周节省 11.4 小时，每月 45+ 小时**，相当于 2 个完整工作日。 + +而他做到的这件事本身就很有意思：**没有 API、没有复杂集成、没有终端命令**。只是用 Claude 网页版 Pro 订阅，加上 10 个精心设计的工作流程。 + +这就是今天要聊的——不是怎么用 AI，而是怎么系统地用 AI。 + +--- + +## 为什么零散的提示词是个坑 + +先说个常见的误区。很多人用 AI 是这样的：想起一件事，扔一段话过去；再想起一件事，再扔一段。偶尔有惊喜，大多数时候在后悔——输出要么太泛，要么漏了关键信息，要么格式乱七八糟。 + +这不是 AI 的问题，是使用方式的问题。 + +零散的提示词有几个致命伤： + +- **不可复制**：今天写的提示词，明天遇到类似任务就得重写一遍。脑子记不住那么多细节，版本一多就乱。 +- **结果不稳定**：同一类型的任务，这次输出 A，下次输出 B，质量全凭运气。 +- **每次都要校准**：你得花时间解释背景、格式要求、目标读者——这些摩擦累积起来，比"不用 AI"还累。 + +Zodchiii 的洞察很准确：**工作流程不是提示词，是一个系统**。固定输入格式、固定输出结构、可预测的结果、同类任务的通用解决方案。 + +换句话说：把"每次都要重新发明轮子"变成"一次构建，反复使用"。 + +--- + +## 10 个高 ROI 工作流程 + +下面这 10 个工作流程，是从实际使用中提炼出来的。每个都标明了时间节省幅度，都是 Zodchiii 实测过的。 + +### 1. 内容研究 +**从 4 小时压缩到 1.5 小时，每周节省 2 小时 30 分钟** + +这个流程解决的是写内容前的"调研地狱"——翻资料、找数据、辨真伪，一不小心就耗掉半天。 + +**English:** +``` +Here are my sources on [TOPIC]: +[PASTE ALL RAW MATERIAL] + +Extract: +1. The 5 facts that matter most for my audience (builders, not consumers) +2. Anything that contradicts the common narrative +3. Specific numbers: stars, users, funding, benchmarks +4. One angle nobody else is covering + +If two sources disagree, show me both sides. +Don't summarize fluff. Only signal. +``` + +**中文版：** +``` +以下是我收集的关于 [主题] 的原始材料： +[粘贴所有原始内容] + +请提取： +1. 对我的受众最重要的 5 个事实（我的受众是实践者，不是旁观者） +2. 与主流叙事相矛盾的任何信息 +3. 具体数字：GitHub star 数、用户量、融资金额、性能基准 +4. 一个目前没人覆盖的角度 + +如果两个来源互相矛盾，同时展示双方观点。 +不要总结空洞的套话，只提炼有价值的信息。 +``` + +关键点：**直接粘贴原始材料，让 AI 做提炼，而不是让它"随便聊聊"**。模糊的要求产生模糊的结果，给定结构才能得到结构。 + +--- + +### 2. 快速研究 +**从 2 小时砍到 15 分钟，每周节省 1 小时 45 分钟** + +当你不了解某个领域、需要快速建立认知时，这个流程比 Google 搜索加阅读十篇文章高效得多。 + +**English:** +``` +Research [TOPIC]. Structure: +1. Executive summary (3 sentences max) +2. Key findings (top 5, ranked by impact) +3. What's missing: gaps in available info +4. Sources with URLs + +If data is insufficient for any claim, say so. +Don't speculate. Don't pad. +``` + +**中文版：** +``` +研究 [主题]，结构如下： +1. 执行摘要（最多 3 句话） +2. 关键发现（Top 5，按影响力排序） +3. 缺失信息：现有资料中的空白 +4. 来源（带 URL） + +如果数据不足以支撑某个结论，如实说明。 +不要猜测，不要填充废话。 +``` + +这个模板的价值在于**强制简洁**。3 句话说完核心观点，然后才是细节。如果你发现 AI 在"填充废话"，说明你问的问题本身就太空泛。 + +--- + +### 3. 内容重构 +**从 2 小时压缩到 20 分钟，每周节省 1 小时 40 分钟** + +写完一篇文章后，最痛苦的不是写本身，而是改写成不同格式发不同平台。这个工作流程让 AI 帮你一次性搞定 Twitter/X、LinkedIn、Newsletter 等多个渠道。 + +**English:** +``` +Here's my article: [PASTE OR UPLOAD] + +Create: +1. A 2-sentence hook for X (include a specific number or claim from the article) +2. A 4-paragraph TG post with the key insight +3. A provocative quote-tweet caption (1 sentence) +4. 3 standalone insights that work as separate tweets throughout the week + +Each piece must work independently. +Someone who never read the article should still get value. +``` + +**中文版：** +``` +以下是我的文章：[粘贴或上传] + +请创建： +1. 一条 X 推文的两句话钩子（必须包含文章中的一个具体数字或观点） +2. 一篇 4 段 Telegram 帖子，突出核心洞察 +3. 一条引发讨论的引用推文配文（1 句话） +4. 3 个独立的洞察，可作为本周不同时段分别发布的推文 + +每个内容都必须独立可读。 +哪怕对方没读过原文，也要能从这条内容里获得价值。 +``` + +**一鱼多吃**。好的内容值得多平台分发，但手动改写是时间黑洞。这个流程保证每个版本都是独立可读的，不是简单的"复制粘贴换格式"。 + +这个流程还能**反向操作**——把零散的帖子整合成长文章： + +**English:** +``` +Here are 5-6 short TG posts from this week: [PASTE ALL] + +Find the connecting thread and draft a long-form article outline. +``` + +**中文版：** +``` +以下是本周的 5-6 条短帖：[粘贴所有内容] + +找出它们之间的连接线，起草一篇长文的提纲。 +``` + +--- + +### 4. 数据洞察 +**从 2 小时砍到 20 分钟，每周节省 1 小时 40 分钟** + +面对一份数据集，大部分人要么不知道从何下手，要么看完只记得"数字挺多"。这个流程让 AI 先做初步分析，你再决定深挖哪里。 + +**English:** +``` +Analyze this data. I need: +1. Top 3 trends over time +2. Anything unusual or unexpected +3. Correlations between [COLUMN A] and [COLUMN B] + +Table first, then a 2-paragraph summary explaining +what this means in plain English. +If the dataset is too small for a conclusion, say so. +``` + +**中文版：** +``` +分析这份数据，我需要： +1. 时间维度的 Top 3 趋势 +2. 任何异常或出乎意料的发现 +3. [A 列] 和 [B 列] 之间的相关性 + +先出表格，再出两段总结，用通俗语言解释这意味着什么。 +如果数据集太小无法得出结论，如实说明。 +``` + +**先出表格，再给解读**——这个顺序很重要。表格是原始信息，解读是认知结论。混在一起写很容易变成"看似有道理但不可验证"的废话。 + +--- + +### 5. 代码审查 +**从 2 小时压缩到 15 分钟，每周节省 1 小时 45 分钟** + +代码审查是个技术活，但大部分审查时间其实花在"找常规问题"上——安全漏洞、代码风格、性能隐患。AI 擅长干这个，而且不会累。 + +**English:** +``` +Review this code for: +- Security issues (exposed keys, injection, XSS) +- Logic errors and edge cases I might have missed +- Performance problems +- Anything that would make a senior dev uncomfortable + +For each issue: severity (Critical/High/Medium/Low), +exact location, why it matters, and the corrected code. + +Be harsh. "Looks good overall" is not helpful. + +[PASTE CODE] +``` + +**中文版：** +``` +审查这段代码，重点关注： +- 安全问题（泄露的密钥、注入漏洞、XSS 等） +- 逻辑错误和我可能遗漏的边界情况 +- 性能问题 +- 任何让高级工程师看了不舒服的地方 + +每个问题请注明：严重程度（Critical/High/Medium/Low）、 +具体位置、为什么重要，以及修正后的代码。 + +要严厉。"整体看起来还行"这种反馈没有帮助。 + +[粘贴代码] +``` + +这里有个心态要调整：代码审查不是"证明我很仔细"，而是"发现真正的问题"。AI 帮你过滤掉 80% 的常规问题，你就可以专注在架构层面的判断。 + +--- + +### 6. GitHub 仓库分析 +**从 1.5 小时压缩到 20 分钟，每周节省 1 小时 10 分钟** + +为了写一篇关于 AI 工具的文章，需要从 1000 多个仓库中筛选出真正值得提及的项目。手动检查需要 50+ 小时，AI 帮你大幅缩减这个过程。 + +**English:** +``` +Here's a list of GitHub repos with descriptions: +[PASTE BATCH] + +For each repo, evaluate: +1. What it actually does (1 sentence, no marketing speak) +2. Traction signals: stars, recent commit activity, contributor count +3. Category: agent framework / dev tool / MCP / infrastructure / other +4. Worth featuring? Yes/No with one reason + +Skip anything that's just a wrapper, a tutorial repo, +or has no commits in 30+ days. +Sort the "Yes" picks by most interesting first. +``` + +**中文版：** +``` +以下是 GitHub 仓库列表及描述：[粘贴批次] + +对每个仓库评估： +1. 它实际做什么（1 句话，不许用营销语言） +2. 增长信号：star 数、最近提交活跃度、贡献者数量 +3. 分类：Agent 框架 / 开发工具 / MCP / 基础设施 / 其他 +4. 值得推荐吗？是/否，附一个理由 + +跳过那些只是包装层、教程仓库、或 30 天以上无提交的项目。 +把"值得推荐"的选项按价值从高到低排序。 +``` + +分批处理 50-100 个仓库，自动过滤废弃项目（30 天无提交）。这个流程把需要手动检查的数量从 1000 个减少到 80 个。 + +--- + +### 7. 竞争对手分析 +**从 1 小时压缩到 15 分钟，每周节省 45 分钟** + +分析竞争对手的内容、定位和受众通常需要 1 小时，AI 帮你快速建立结构化认知。 + +**English:** +``` +I'm analyzing [COMPETITOR/ACCOUNT]. + +Based on what you know + the data I'm providing: +1. Top 3 things they're doing well (be specific) +2. Gaps or weaknesses in their approach +3. What I can learn from them +4. How my positioning is different + +About me: I write about AI tools, vibe coding, and crypto +for builders. TG + X. + +Don't say "they have a strong brand." +Tell me WHY and what specifically makes it work. +``` + +**中文版：** +``` +我在分析 [竞争对手/账号]。 + +基于我所知道的信息 + 我提供的资料： +1. 他们做得最好的 3 件事（要具体） +2. 他们方法中的漏洞或薄弱环节 +3. 我可以从他们身上学到什么 +4. 我的定位有何不同 + +关于我：我的受众是 AI 工具实践者、Vibe Coder、 +Crypto 建设者。发布渠道是 Telegram + X。 + +不要说"他们有很强大的品牌"这种废话。 +告诉我是**为什么**，是什么具体因素让他们的做法有效。 +``` + +必须提供"我是谁"的上下文。没有这个，你会得到一份通用的 SWOT 分析，而不是有针对性的洞察。 + +--- + +### 8. 晨间简报 +**从 45 分钟压缩到 5 分钟，每周节省 40 分钟** + +每天早上刷 X"保持更新"需要 45 分钟，还会被各种噪声干扰。AI 帮你过滤掉 95% 的噪声。 + +**English:** +``` +3-minute briefing: +1. Top 3 AI news from last 24 hours (one sentence each) +2. Crypto: major moves, liquidations, new narratives +3. Anything I should know before posting content today + +Be specific: names, numbers, links. +Skip anything that isn't genuinely important. +3 real updates > 10 filler items. +``` + +**中文版：** +``` +给我一个 3 分钟简报： +1. 过去 24 小时 Top 3 AI 新闻（每条一句话） +2. Crypto 动态：主要行情、清算情况、新兴叙事 +3. 今天发内容前需要知道的事 + +要具体：人名、数字、链接。只选真正重要的信息。 +3 条真实更新 > 10 条凑数的废话。 +``` + +为什么比直接刷社交媒体更好：消除了噪声和分心，只提供真正重要的信息，用结构化的方式呈现，每天节省 40 分钟。 + +--- + +### 9. 邮件起草 +**从 30 分钟压缩到 5 分钟，每周节省 25 分钟** + +写 4 句话的邮件需要 15 分钟思考语气——太正式像机器人，太随意不专业。AI 帮你处理措辞。 + +**English:** +``` +Draft an email. +To: [NAME + how I know them] +Goal: [WHAT I WANT THEM TO DO] +Tone: professional but sounds like a real person +Max: 5 sentences +Context: [THE SITUATION] + +Does not sound like: a cold pitch template, corporate speak, +or something ChatGPT would write. +No "I hope this email finds you well." +``` + +**中文版：** +``` +起草一封邮件。 +收件人：[姓名 + 我是怎么认识他们的] +目标：[我希望他们做什么] +语气：专业但听起来像真人 +长度：最多 5 句话 +背景：[具体情况] + +不要写成：冷冰冰的模板套话、企业黑话、 +或 ChatGPT 会写的那种。 +不要用"希望此邮件您一切安好"这种开头。 +``` + +成功的关键是**说清楚你要什么，而不是让 AI 猜**。"写封邮件"是模糊指令，"写封措辞坚定但不失礼貌、要求对方在周五前确认方案的邮件"才是可执行的指令。 + +--- + +### 10. 每周回顾 +**从 1 小时压缩到 30 分钟，每周节省 30 分钟** + +整理一周的笔记和想法需要 1 小时，还容易遗漏重要模式。AI 帮你从上帝视角看自己。 + +**English:** +``` +Here are my notes and ideas from this week: [PASTE EVERYTHING] + +Help me: +1. Find patterns: what topics am I gravitating toward? +2. Which 3 ideas have the most content potential? +3. What am I ignoring that I shouldn't be? +4. Content plan for next week: 3 TG posts + 1 article topic + +Be honest. If an idea is weak, say so. +Don't tell me everything is great. +``` + +**中文版：** +``` +以下是我本周的笔记和想法：[粘贴所有内容] + +帮我： +1. 找到模式：我正在被哪些话题吸引？ +2. 哪 3 个想法的内容潜力最大？ +3. 我在忽略什么不该忽略的东西？ +4. 下周内容计划：3 篇 Telegram 帖子 + 1 个文章选题 + +要诚实。如果某个想法很弱，直接说。 +不要告诉我一切都很棒。 +``` + +AI 作为思考伙伴的价值：识别你可能忽略的模式和连接，帮助你看到更大的画面，提供诚实的反馈而不是无意义的赞美，提前规划下周的内容，避免"写什么"的焦虑。 + +--- + +## 时间节省数据：每分钟都花在刀刃上 + +| 工作流程 | 手动所需时间 | AI 处理时间 | 每周节省 | +|---------|------------|------------|---------| +| 内容研究 | 4 小时 | 1.5 小时 | 2 小时 30 分钟 | +| 快速研究 | 2 小时 | 15 分钟 | 1 小时 45 分钟 | +| 数据洞察 | 2 小时 | 20 分钟 | 1 小时 40 分钟 | +| 代码审查 | 2 小时 | 15 分钟 | 1 小时 45 分钟 | +| GitHub 仓库分析 | 1.5 小时 | 20 分钟 | 1 小时 10 分钟 | +| 内容重构 | 2 小时 | 20 分钟 | 1 小时 40 分钟 | +| 竞争对手分析 | 1 小时 | 15 分钟 | 45 分钟 | +| 晨间简报 | 45 分钟 | 5 分钟 | 40 分钟 | +| 邮件起草 | 30 分钟 | 5 分钟 | 25 分钟 | +| 每周回顾 | 1 小时 | 30 分钟 | 30 分钟 | +| **总计** | **~16 小时** | **~3 小时** | **约 13 小时/月** | + +> 注：以上数字为 Zodchiii 个人实测数据。你的结果取决于工作性质和当前流程的摩擦程度。但即使只采用 3-4 个工作流程，每月节省 5+ 小时也很现实。 + +--- + +## 深刻的洞察：时间的真相 + +从这次追踪中，Zodchiii 得出了一个比节省时间更深刻的结论：**大多数"工作"其实是摩擦。** + +我们的时间都花在哪里了？ + +- **上下文切换**：打开标签页、重新阅读、重新定位——每次切换消耗 15-20 分钟 +- **重复性整理**：同样的信息整理工作一遍又一遍——每次都是"重新发明轮子" +- **噪声过滤**：从大量无关信息中找出有价值的那一条——大海捞针 +- **格式化劳动**：把同一份内容改写成不同格式——技术含量低但极其耗时 + +**AI 改变了什么？** + +AI 并没有替代人类的工作，它替代了围绕工作的摩擦。真正需要人类的部分——思考、决策、编辑——仍然保留，但这些部分的效率大幅提升。 + +**核心纠正**：很多人说"AI 不能做我的工作"，这通常是对的。但 AI 可以做围绕你工作的 60% 的摩擦性任务，而这 60% 正是时间浪费最严重的地方。 + +--- + +## 建立工作流程的实践指南 + +### 步骤 1：识别高摩擦任务 + +查看你的工作日，问自己： + +- 哪些任务我每周至少做 2 次？ +- 哪些任务需要重复相同的步骤？ +- 哪些任务让我感到无聊或烦躁？ + +这些都是建立工作流程的理想候选。 + +### 步骤 2：分析当前流程 + +记录你现在完成该任务的步骤： + +- 需要什么输入？ +- 需要什么输出？ +- 有哪些可预测的部分？ +- 哪里最容易出错？ + +### 步骤 3：创建结构化提示词 + +基于分析结果，创建一个包含以下元素的提示词： + +- 明确的任务描述 +- 输入格式要求 +- 输出结构模板 +- 质量控制标准（如"要严厉""不要猜测"） +- 成功的关键要素 + +### 步骤 4：测试和优化 + +使用这个提示词完成几次任务，然后问自己： + +- 结果是否符合预期？ +- 还需要什么调整？ +- 如何让它更精确？ + +### 步骤 5：记录和标准化 + +一旦工作流程稳定下来，记录： + +- 任务类型 +- 输入要求 +- 提示词模板 +- 预期输出格式 +- 常见问题和解决方案 + +--- + +## 常见误区和避免方法 + +**误区 1：追求完美** ：工作流程不需要完美，只需要比手动更快。追求完美会让你永远无法开始。 + +**误区 2：一次建立太多** ：从 1-2 个高价值工作流程开始，验证有效后再扩展。贪多嚼不烂。 + +**误区 3：忽视质量控制** ：在提示词中加入质量要求（如"要严厉""只提炼信号"），定期验证结果，不要让 AI 输出成为新的噪声来源。 + +**误区 4：建立后不再更新** ：定期回顾工作流程，根据使用反馈持续迭代。一次性工作流程不如持续优化的系统。 + +**误区 5：忽视人机边界** ：AI 擅长执行和整理，不擅长判断和决策。工作流程应该把"需要判断的事"留给人类，把"重复性执行"交给 AI。 + +--- + +## 未来趋势：接下来会发生什么 + +**短期（6-12 个月）** + +1. **工作流程智能化**： AI 将更好地理解个人工作风格，主动推荐优化空间，而不只是被动响应 +2. **跨平台连接**： 工作流程将能与更多工具（Notion、Linear、Slack）直接集成，减少手动复制粘贴 +3. **结构化提示词市场**： 会出现经过验证的高质量提示词模板市场，降低"从零构建"的门槛 + +**中期（1-2 年）** + +1. **个性化工作流程引擎**： 基于你的历史行为数据，自动生成和优化工作流程，人类从"构建者"变成"审核者" +2. **多 Agent 协作**： 复杂任务将由多个 AI Agent 分工完成，每个 Agent 专注一个工作流程，形成流水线 + +**更重要的趋势** + +AI 工作流程的普及将重新定义"专业能力"的含义： + +- **会提问比会执行更重要**： 未来最稀缺的能力是清晰定义问题，而不是熟练操作工具 +- **判断力成为核心竞争力**： AI 能做执行，但判断"做什么"、判断"结果对不对"仍然需要人类 +- **系统化思维成为必备技能**： 能把重复性任务抽象为流程的人，和只会一个个完成任务的人，效率差距会越拉越大 + +--- + +## 写在最后 + +45 小时听起来很多，分摊到每个月其实也就是每天多出 1.5 小时。 + +但这 1.5 小时不是从天上掉下来的——它是把那些本该花在"操作"上的精力，转移到"思考"上的结果。 + +AI 不会替你做决定，但可以替你做执行。把时间从执行层抽出来，放到真正需要判断力的地方，这才是使用 AI 的正确姿势。 + +剩下的，就是选一个工作流程，今天就开始。 + +--- + +> 注：本文基于 Zodchiii 在 Twitter/X 上的分享。更多日常笔记和 AI 实践心得，可以在她的 Telegram 频道（t.me/zodchixquant）中找到。 diff --git "a/ai-articles/01-agent-and-coding/\345\275\223 Claude Opus 4.6 \351\201\207\344\270\212 GPT-5.3-Codex.md" "b/ai-articles/01-agent-and-coding/\345\275\223 Claude Opus 4.6 \351\201\207\344\270\212 GPT-5.3-Codex.md" new file mode 100644 index 0000000..3997e16 --- /dev/null +++ "b/ai-articles/01-agent-and-coding/\345\275\223 Claude Opus 4.6 \351\201\207\344\270\212 GPT-5.3-Codex.md" @@ -0,0 +1,97 @@ +# 当 Claude Opus 4.6 遇上 GPT-5.3-Codex + +> 日期：2026-02-07 + +[toc] + +想象一下，如果两个世界上最聪明的大脑宣布自己又加了一层智力提升 200 的 buff 。。。。。。 + +这就是2026年2月6日发生的事。 +这一天，人工智能领域的两大巨头Anthropic和OpenAI，各自亮出了最新王牌：**Claude Opus 4. 6**和**GPT-5.3-Codex**。 + +这不是简单的版本更新，更像是一场 AI 界的“春晚”，两位主角都想证明自己的“智力进化路径”才是未来。而最有趣的是，它们的性格和能力差异，简直像是从不同科幻电影里走出来的角色。 + +## 两种角色，两套哲学 + +Anthropic 和 OpenAI ，就像是两种出身不同的人一样，他们也拥有不同的哲学。 + +**Claude Opus 4.6**像是**常春藤联盟的终身教授**。它出生于以“安全第一”著称的Anthropic实验室，被训练得深思熟虑、严谨可靠。它相信好的答案需要时间酝酿，所以当你问它复杂问题时，它会像准备学术论文一样构建论点、寻找证据。 + +面对复杂问题，它会先推一推眼镜说：“让我仔细分析一下这个问题......” + +**GPT-5.3-Codex**则像是**硅谷创业公司的技术天才**。它来自追求极致效率的OpenAI，信奉“行动胜过完美”。如果你告诉它“我想要一个网站”，它不会先写20页需求分析，而是直接开始敲代码，边做边问：“首页要红色还是蓝色？” + +然后在你思考的间隙，已经敲出了 10 行代码。 + +## 超能力大比拼：当“记忆大师”遇上“执行狂魔” + +### Claude的绝活：真正的“过目不忘” + +传统AI有个致命弱点——记性差。给它们一本长篇小说，读到后面就忘了前面。 + +就拿大多数开发者都头疼上下文 token 的问题来举例子，往往你正在 vibe coding 正爽的时候 token用完了，只能重新换个新的任务重新执行。但 Claude Opus 4.6解决了这个问题。 + +它现在能**一次性处理超过100万tokens的文本**（相当于70多万汉字，约3本《红楼梦》）。更厉害的是，它在这“信息海洋”中找东西的能力大幅提升——想象一下把一根针扔进太平洋，然后准确捞出来。在实际测试中，**它在这种“大海捞针”任务中的准确率，从前代的18.5%飙升至76%**。 + +图像 + +这意味着什么？ + +- 律师可以扔给它**整个并购案的所有文件**，让它找出风险条款。 +- 研究员可以上传**几十篇学术论文**，让它总结共识与争议。 +- 作家可以把**全部手稿和笔记**交给它，请求结构优化建议。 + +### Codex的杀手锏：从“建议者”到“执行者” + +如果Claude是记忆大师，Codex就是执行领域的革命者。 + +之前，AI更像是“顾问”——给你建议，但活还得你自己干。GPT-5.3-Codex改变了游戏规则，它变成了**能真正干活的“数字员工”**。在专门测试AI真实环境操作能力的OSWorld测试中，**它的成绩从前代的38.2%跃升至64.7%**——这个进步相当于从“偶尔能完成任务”变成了“大多数时候靠谱”。 + +![图像](https://pbs.twimg.com/media/HAcOJC_acAAH_2Q?format=png&name=900x900) + +最酷的是它的工作方式：你可以把它派去执行一个复杂任务（比如“优化我们的网站加载速度”），它会**像人类同事一样，中途给你发“进度报告”**：“已完成图片压缩，正在调整代码结构，预计还需要15分钟。对了，我发现数据库有个潜在问题，要一并处理吗？” 这简直太可爱了。 + +## 职场比拼 + +当Claude成为你的同事： + +**上午9：00**，你打开邮箱，一份关于竞争对手动态的深度分析报告已经静静躺在那里——它分析了对方近三个月的所有公开信息，连CEO在行业论坛上的发言都没放过。 + +**上午10：30**，你需要准备下午董事会的PPT。在PowerPoint里输入：“用这三组数据做个汇报，风格要专业但不死板。”十分钟后，一套设计精美的幻灯片准备就绪，连动画效果都恰到好处。 + +**下午2：00**，新项目启动。Claude默默分裂成四个专业角色：一个负责架构设计，一个专注编码实现，一个检查潜在错误，还有一个撰写技术文档。最后，它像经验丰富的项目经理，将所有成果无缝整合。 + +当Codex加入你的团队： + +**凌晨3：00**，你突然灵光一闪：“做个能记录梦境的小程序吧！”半梦半醒间给Codex下达指令。天亮时，一个具备语音输入和情绪分析功能的可运行原型已经准备好了。 + +**上午10：00**，每日站会。Codex主动汇报：“昨晚拦截了5次攻击尝试，优化了数据库查询，网站平均响应时间缩短了23%。”比你想象中更细致。 + +**下午3：00**，你突发奇想：“让我们的在线商店更吸引Z世代。”Codex不会反问“具体要怎么做”，而是直接分析数据、研究趋势，提出完整方案，甚至已经开始修改部分页面。 + +反正对于现在 1 人公司的创业者来说，大家都很开心。 + +## 哲学之争：副驾驶还是自动驾驶？ + +这次同步发布背后，是两种AI哲学的根本分歧。 + +**Anthropic走的是“增强人类”路线**——AI应该是强大的工具，放大人类的智慧，但关键决策权永远在人类手中。他们的AI更像**副驾驶**，随时准备协助，但方向盘始终在你手里。 + +**OpenAI则选择了“自主智能体”方向**——AI应该能独立完成任务，成为真正的数字同事。他们的AI更接近**自动驾驶系统**，设定目的地后，它自己会处理大部分路况。 + +这种分歧就像育儿观念的差异：一方认为应该给予指导但放手让孩子尝试；另一方相信只有充分自主，孩子才能真正成长。 + +## AI 套娃 + +在这场竞争中，一些有趣的小细节格外引人注目： + +- **自我进化**：GPT-5.3-Codex在开发过程中，**使用了早期版本帮助调试和改进自己**——这可能是第一个在自身创造中发挥关键作用的AI，有点像“自己生了自己”的科幻情节。终于能解释清楚先有鸡再有蛋的问题了。 + +- **价格哲学**：Claude像高级餐厅——按菜收费（根据使用量计费）；Codex像自助餐——先买门票（订阅制），进去后随意使用。哪种更划算？取决于你的“食量”。 +- **网络安全双刃剑**：OpenAI自己将Codex归类为网络安全“高能力”模型——这意味着它既是坚不可摧的盾，也可能是无坚不摧的矛。工具本身没有善恶，全看掌握在谁手中。 + +## 用哪个呢？ + +对于纠结“该选哪一个”的人们，这个答案已经不攻自破：**为什么不两个都要？** + +一个是**哆啦A梦的口袋**，一个是**海豹突击队**，你觉得用哪个合适？ diff --git "a/ai-articles/01-agent-and-coding/\345\276\256\344\277\241\345\256\214\345\205\250\346\216\245\345\205\245 OpenClaw \346\214\207\345\215\227.md" "b/ai-articles/01-agent-and-coding/\345\276\256\344\277\241\345\256\214\345\205\250\346\216\245\345\205\245 OpenClaw \346\214\207\345\215\227.md" new file mode 100644 index 0000000..d70d5a7 --- /dev/null +++ "b/ai-articles/01-agent-and-coding/\345\276\256\344\277\241\345\256\214\345\205\250\346\216\245\345\205\245 OpenClaw \346\214\207\345\215\227.md" @@ -0,0 +1,193 @@ +# 微信终于支棱起来了 + +> 日期：2026-03-22 + +千呼万唤始出来！微信终于正式将 **OpenClaw** 接入生态，而且这次的方式堪称“史诗级”升级——它不再是躲在角落里的客服消息，而是以**独立小窗**的形式，直接在聊天窗口中运行！ + + + +这无疑是所有 ClawBot 用户的福音。今天，我们就为大家带来一篇完整的微信接入 ClawBot 教程，手把手带你体验这个全新的功能。 + + + +image-20260322141732434 + + + +目前，微信接入 ClawBot 主要有两种方式，你可以根据自己的情况选择： + + + +1. **原生 OpenClaw 接入**：将 ClawBot 直接作为你部署的 OpenClaw 服务接入，适合已经拥有自己服务器的用户。 + + + +2. **QClaw 快速接入**：通过 QClaw 客户端一键接入，配置更简单，适合希望快速上手的用户。 + + + +**无论你选择哪种方式，都有一个硬性前提：请务必将手机微信更新至 8.0.70 版本。** + + + +bbbf4119de0a41dbbc643cd284fe16f2 + + + +然后点击上图中的**插件**功能，可以看到有 Clawbot （如果看不到的话，需要杀掉一下微信后台进程，重新进入微信即可）。 + + + +![](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260322142633395.png) + + + +点进去详情，你会看到两种连接方式。我们先来看第一种——原生 OpenClaw 接入。 + + + +这种方式适合已经部署了 OpenClaw 的用户。你只需在部署了 OpenClaw 的本地电脑、服务器或云服务器上，执行官方提供的一键安装命令即可。 + + + +image-20260322143002384 + + + +我是直接让云服务器上的 Claude 帮我安装完了。 安装完成后，会弹出一个二维码，使用上图中的扫一扫即可连接。 + + + +image-20260322150438321 + + + +接入完成之后，就可以实现在微信上通过 Clawbot 实现与 OpenClaw 的对话了。 + + + +![](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260322152217724.png) + + + +但是现在 mac 端还不支持 Clawbot ，只有 ios 端可以。所以 mac 上还不显示 ClawBot 的窗口。 + + + +>目前 Clawbot 暂不支持 Mac 端，仅有 iOS 端可以体验独立小窗。这里也隔空喊话一下微信官方：**请尽快适配 Mac 端！** + + + +如果你觉得部署 OpenClaw 稍显复杂，那么 QClaw 是你的不二之选。 + + + +QClaw 刚刚发布了 **0.1.15 版本**，这是一个重大更新，核心功能就是支持与微信 Clawbot 插件直连。 + + + +如果你已经下载了 QClaw，只需在 QClaw 客户端中找到 **「远程连接」** 功能，生成一个连接二维码。然后，同样使用微信 Clawbot 插件页面的扫一扫功能，即可完成接入。 + + + + + + + + + +![](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260322154027572.png) + + + +微信这次将 ClawBot 以独立小窗的形式接入，极大地提升了交互体验，无论是通过原生 OpenClaw 还是 QClaw，都能让你在微信中无缝享受智能对话助手的便利。 + + + +可以说 AI 的门槛被微信给干没了。 + + + +这不再是一个简单的 AI 聊天机器人，而是一种全新的交互范式的预演，是微信生态的重塑。 + + + +当 ClawBot 以插件形式存在，这个定位本身就很值得展开想象。如果AI 插件成为一种标准化的微信能力，未来我们可能会看到： + +- **法律助手ClawBot**：接入专业法律知识库，帮你审合同、解答法律咨询 + + + +- **医疗顾问ClawBot**：结合症状库和健康建议，提供初步的健康咨询 + + + +- **学习伴侣ClawBot**：接入题库和知识点，成为随时在线的家教 + + + +- **编程助手ClawBot**：专门解决代码问题，支持代码片段直接运行 + + + +每个插件都可以是一个独立的小窗，用户按需添加，就像现在添加小程序一样。 + + + +就像是 MCP 和 Skills 的爆火一样，相信微信未来也会集成外部调用工具和技能，而 ClawBot 作为核心主控，可以调用其他专业插件完成任务。 + + + +可以想象一下：在群里讨论周末去哪玩，你只需要 @ClawBot，它自动搜索目的地、对比价格、整合攻略，甚至帮你拉起订票小程序——这一切都在一个对话流中完成。 + + + +值得一提的是，这次微信生态接入 ClawBot，背后下了不少功夫。甚至连腾讯云都为此发布了一张充满创意的“神图”，可见对这次合作的重视程度。 + + + +image-20260322155030997 + + + +当然这不仅仅是一张神图，你可以从这张图中窥见未来的微信生态的**雏形**。 + + + +1. **云原生底座**：ClawBot 的稳定运行离不开云端算力支持，腾讯云很可能在背后提供了弹性计算和 API 网关服务。 + + + +2. **生态联动**：图中暗示了 ClawBot 可能与腾讯会议、企业微信、腾讯文档等产品形成联动。 + + + +3. **开发者激励**：未来可能会有“ClawBot 插件开发者计划”，鼓励第三方开发垂直领域的 AI 插件。 + + + +这意味着，微信的 AI 插件模式可能不仅仅是一个功能，而是一个**完整的生态平台战略**——腾讯提供底层算力和分发渠道，开发者贡献垂直能力，用户获得丰富体验。 + + + +当然，这种模式的未来并非一片坦途，有几个关键问题值得关注，尤其是**隐私安全问题**——官媒已经多次强调过这一点。 + + + +1. **隐私与数据边界** ：当AI插件能够读取聊天内容、调用个人信息时，隐私保护如何保障？用户能否精细控制每个插件的权限？这可能是最核心的挑战。 + + + +2. **商业化路径** ：目前 ClawBot 是免费使用的，但未来如果出现大量第三方插件，如何设计商业模式？这需要谨慎探索。 + + + +3. **Mac 端适配**：正如原文中提到的，目前 Mac 端还不支持 ClawBot 小窗。对于大量在电脑上使用微信的用户来说，这是一个明显的短板。希望官方能够尽快补上这一环。 + + + +4. **生态治理**：当插件数量增多，如何保证质量？如何防止恶意插件？如何建立审核和评价机制？这些都是微信团队需要提前布局的。 + + + +不过我仍然相信微信的安全防范能力。我之前开发过一款工具，仅仅是想监听微信小程序的底层 API，结果耗费了大量功夫——毫无进展！微信在安全这块，确实把门焊得很死。 diff --git "a/ai-articles/01-agent-and-coding/\346\210\221\346\234\200\350\277\221\346\234\200\345\270\270\347\224\250\347\232\204 10 \344\270\252 Codex \346\212\200\345\267\247.md" "b/ai-articles/01-agent-and-coding/\346\210\221\346\234\200\350\277\221\346\234\200\345\270\270\347\224\250\347\232\204 10 \344\270\252 Codex \346\212\200\345\267\247.md" new file mode 100644 index 0000000..faa246d --- /dev/null +++ "b/ai-articles/01-agent-and-coding/\346\210\221\346\234\200\350\277\221\346\234\200\345\270\270\347\224\250\347\232\204 10 \344\270\252 Codex \346\212\200\345\267\247.md" @@ -0,0 +1,408 @@ +# 我最近最常用的 10 个 Codex 技巧 + +> 日期：2026-06-09 + + +这两天我发现一个问题。 + +Codex 我用得越多，越不想让它一上来就改代码。 + +最开始我的用法很直接：打开 Codex，输入一句“帮我实现一下”，然后等它改代码。 + +现在不是这样了。 + +现在我会先让它把计划说清楚，再调整权限。跑完一轮后，再看 diff、页面和测试结果。 + +原因也简单：这样很容易返工。 + +现在大家应该都不在怀疑 Agent 能力了，存疑的是 Agent 会不会能力太强，改动太大。 + +你让它改一个按钮，它可能额外整理 import、改公共组件，把一个小问题带成一次小重构。 + +这样就造成额外的不必要的工作量。 + +这篇我讲一下我自己最常用、也确实能减少返工的 10 个技巧。 + +![Codex goal](../../assets/article-images/2026-06-codex-top10-tips/01-codex-app-commands.webp) + +*图源：OpenAI Codex app commands 文档，searchnews 已本地保存* + +--- + +## 先让它出计划 + +第一个技巧是 `/plan`。 + +这个命令我现在基本会在两类场景里先用：跨文件修改，或者我自己还没完全想清楚的需求。 + +以前我经常直接说“帮我改一下”。Codex 很快就会开始修改。 + +问题是，修改开始得越快，越容易跳过边界确认。 + +因为它还没讲清楚三件事：准备改哪里，怎么验证，哪些地方不能碰。 + +我现在常用的提示词大概是这样： + +```text +先不要改代码。 + +请先读相关文件，给我一个计划： +1. 要改哪些文件。 +2. 哪些地方不碰。 +3. 改完怎么验证。 +4. 这件事最容易出问题的点是什么。 +``` + +这一步会多花一点时间，但能减少后面的返工。 + +你会很快发现它有没有理解错需求，有没有准备动一个不该动的模块，有没有把验证写成一句没有依据的“应该没问题”。 + +**Agent 写代码越快，开工前那一分钟越应该花。** + +第二个技巧是 `/goal`。 + +这个适合长任务，比如迁移、重构、批量修复、整理一堆历史问题。 + +但我现在不会直接写“把这个项目优化一下”。 + +这种 goal 太宽泛，执行过程中容易偏离目标。它会一直推进，但你不知道它到底离完成标准还有多远。 + +我会给它一个终点线： + +```text +目标：把这个模块从旧接口迁移到新接口。 + +完成标准： +- 相关单测全部通过。 +- 页面原有行为不变。 +- 不改认证逻辑。 +- 收尾输出改动文件、验证命令和失败尝试。 +``` + +没有验证方式的 goal，很容易偏离目标。 + +我之前跑过很长的任务，跑到后面 Codex 的回复结构还正常，但方向已经偏了。后来我就养成一个习惯：goal 跑一段，就让它停下来复盘一次计划。 + +问它：现在离终点还差什么？原来的边界有没有被突破？下一步准备干什么？ + +这一步的作用很具体：定期对齐任务状态，防止长任务偏离原始目标。 + +我之前还写过一篇 goal 的用法，你可以看看这篇 [可算是把 goal 玩明白了。](https://mp.weixin.qq.com/s/t4uLnRohUmrcCRJthH-PHw) + +--- + +## 权限按风险给 + +第三个技巧是 `/permissions`。 + +这个我以前也踩过两个坑。 + +一种是权限过窄，什么都问，Codex 频繁中断。另一种是直接给 full access，改动范围很快变大，事后 diff 很难审。 + +现在我会按任务切权限。 + +读代码、查资料、梳理方案，可以宽一点。 + +要写文件、装依赖、跑迁移、动配置，就收紧。 + +如果是支付、权限、数据库迁移、安全配置，我宁愿它多问几次。这里多确认一次，比让高风险改动绕过确认更稳。 + +Codex 现在的权限配置已经能细到文件系统、workspace root、网络域名，甚至能把 `.env` 这类文件直接 deny 掉。 + +第四个技巧是 `AGENTS.md`。 + +这个文件不要写空泛要求。 + +不要写“请保持代码优雅”“请遵循最佳实践”。这种话约束很弱，也不方便后面检查。 + +我会写这种： + +```md +## Verification + +- 修改前端后，要启动本地服务并打开目标页面。 +- 修改 API 行为后，要跑对应测试。 +- 不主动重构未涉及模块。 + +## Review + +- Code review 只报告真实风险，不报风格偏好。 +- 不确定的事实要标注不确定，不要乱补。 + +## Safety + +- 不读取、不修改 `.env`。 +- 不改认证、支付、权限逻辑，除非任务明确要求。 +``` + +Codex 会在开工前读 `AGENTS.md`。全局可以放在 `~/.codex/AGENTS.md`，项目里也可以放一个更具体的。 + +我更建议把它当成工作协议，不要当成偏好合集。 + +第五个技巧是 hooks。 + +有些规则不能只靠提示词。 + +比如不要改 `.env`，不要跑危险命令，改完某类文件自动跑 lint。这些事情，靠 prompt 约束并不稳。 + +该强制执行，就写 hook。 + +Codex 的 hooks 可以插进 agentic loop 里，在工具调用前后、线程开始、子任务启动这些节点触发脚本。非托管 hook 还要 review 和 trust 之后才会跑，这个设计挺合理。 + +我现在对 hooks 的理解是：`AGENTS.md` 负责写规则，hooks 负责在关键节点做校验。 + +一个是规则。 + +一个是校验。 + +前者告诉 Codex 怎么做，后者检查它有没有越过边界。 + +--- + +## 审查前置 + +第六个技巧是 `/diff`。 + +这个命令不显眼，但用习惯之后，能明显降低 review 成本。 + +如果你一直用 xhigh，Codex 的改动范围很容易变大。 + +单个改动规模都不大，加起来 review 成本就上来了。 + +所以我会在它第一轮改完后马上看 `/diff`。 + +用 diff 来看看它的改动和我想要的是否一致。 + +方向对，再继续。 + +方向不对，就在这一轮收住，后面返工会少很多。 + +第七个技巧是 `/review`，再配合行内评论。 + +![Codex review](../../assets/article-images/2026-06-codex-top10-tips/07-codex-pr-review.png) + +*图源：OpenAI Codex code review 示例，searchnews 已本地保存* + +我不会让 `/review` 做宽泛审查。 + +我一般会说： + +```text +review 当前 diff。 + +只看真实风险： +- bug +- 安全问题 +- 回归风险 +- 缺测试 + +不要报风格偏好，不要建议无关重构。 +``` + +这样出来的结果会更接近工程 review，而不是只给出“这里可以更优雅”这种建议。 + +Codex app 的 Review pane 还有一个好用点：可以直接在具体代码行旁边留 inline comment。 + +以前你要重新描述：“你刚才改的那个函数，第三个 if 那里不对。” + +现在直接点到那一行，写一句： + +```text +这里不要吞掉错误，调用方需要知道失败原因。 +``` + +然后告诉 Codex： + +```text +处理这些 inline comments，保持范围最小。 +``` + +这比在聊天框里来回解释更准确。 + +--- + +## 前端必须看页面 + +第八个技巧是 in-app browser。 + +![Codex browser](../../assets/article-images/2026-06-codex-top10-tips/03-codex-browser.webp) + +*图源：OpenAI Codex in-app browser 文档，searchnews 已本地保存* + +我现在对前端任务有一个固定要求： + +**没有打开页面验证，就不要说完成。** + +lint 只能说明代码规则大体通过。 + +测试也覆盖不到所有视觉状态，比如移动端换行、弹窗层级、表单校验、loading、empty 和 error。 + +截图只能说明某个状态下页面正常，不能替代真实点击和多尺寸检查。 + +Codex 的 in-app browser 适合干这类事。你可以让它打开本地 dev server，检查目标页面，点按钮，截图，甚至针对页面上的具体区域留评论。 + +我常用的提示词是： + +```text +启动项目，打开 http://localhost:3000/settings。 + +只检查这个页面： +- 桌面宽度 +- 移动宽度 +- loading / empty / error 三种状态 + +发现视觉问题先截图说明，再改代码。 +``` + +注意这里的关键不是“用浏览器”。 + +关键是把验收对象说清楚。 + +页面是哪一个，状态是哪几个，改动边界是什么。你不说清楚，它就会自己扩大范围。 + +前端任务一旦扩大范围，页面风格和交互细节就容易被改偏。 + +--- + +## 大任务不要堆在一个会话里 + +第九个技巧是 worktrees 和 subagents。 + +我把它们放一起讲，因为它们解决的是同一个问题：不要让一个会话承载太多上下文。 + +![Codex worktree](../../assets/article-images/2026-06-codex-top10-tips/02-codex-worktrees.webp) + +*图源：OpenAI Codex worktrees 文档，searchnews 已本地保存* + +单个 Codex 会话跑久了，context 里会堆满探索记录、失败尝试、日志、临时判断。 + +跑到后面，前面的失败尝试、临时判断和日志会影响后续判断。 + +回复结构还完整，但上下文里已经混入了太多临时判断。 + +Subagent 适合读多写少的活。 + +比如让一个 agent 看安全风险，一个看测试缺口，一个看可维护性。它们各自在自己的上下文里翻材料，再把结论交回来。 + +Worktree 适合会改文件的并行活。 + +比如一个 worktree 修 UI，一个 worktree 查 CI，一个 worktree 做迁移方案。互相不踩文件，也不污染主工作区。 + +但 subagent 和 worktree 都不能滥用。 + +很多任务根本不需要多 agent。任务没拆清楚就拉 subagent，会增加成本、拉长耗时，也会提高合并复杂度。 + +我的判断标准是： + +任务能独立拆开，并且会产生大量日志和探索记录，用 subagent。 + +任务会改文件，而且几条线可能互相影响，用 worktree。 + +只是改一个函数，就不要拆多 agent。 + +--- + +## 重复动作要沉淀下来 + +第十个技巧是 Skills + MCP。 + +![Codex CLI](../../assets/article-images/2026-06-codex-top10-tips/06-codex-cli-terminal.png) + +*图源：OpenAI Codex CLI 示例，searchnews 已本地保存* + +这两个功能不属于同一层，但我自己用的时候经常连在一起。 + +Skills 解决“重复流程”。 + +MCP 解决“外部上下文”。 + +同一段指令反复复制，就适合做成 skill。 + +写公众号文章有写作流程，code review 有审查流程，前端验收有浏览器检查流程。你每次都重新贴一遍，既浪费上下文，也容易贴漏。 + +Codex 的 skill 是按需加载的。它一开始只知道 skill 的名字、描述和路径，实际用到的时候再读完整 `SKILL.md`。 + +所以不要把所有习惯塞进一个很大的“我的工作流”。 + +分窄一点。 + +一个 skill 负责一件事。 + +我会这样分： + +- `wechat-article`：只负责公众号文章写作流程。 +- `frontend-verify`：只负责启动页面、截图、检查移动端。 +- `pr-review`：只负责看 diff 和风险。 + +MCP 则是减少手动复制粘贴。 + +Issue、Figma、浏览器、内部文档、开发者文档，如果有 MCP，就让它靠近原始材料。 + +复制粘贴最大的问题是材料会变形。你复制一段 issue，可能漏了评论；复制一段日志，可能漏了时间；复制一张设计稿截图，可能漏了状态。 + +MCP 解决的是材料来源问题。 + +它让 Codex 直接读 issue、设计稿、内部文档和开发者文档，而不是靠你手动复制一段不完整的上下文。 + +但工具越多，权限边界越要清楚。 + +能读 Figma，不代表它应该自动改设计系统。 + +能看 GitHub，不代表它应该随便推 commit。 + +能查外部网页，不代表网页里的话都可信。 + +所以我自己的组合是：MCP 负责拿材料，skill 负责告诉它怎么处理材料，permissions 和 hooks 负责守边界。 + +这套组合跑顺之后，Codex 的输出会稳定很多。 + +--- + +## 收尾 + +这 10 个技巧背后，其实是一件事。 + +不要把 Codex 只当成聊天回复工具，要把它放进可检查的流程里。 + +今天是 `/plan`、`/goal`、`/diff`、`/review`、Skills、MCP、hooks、worktrees、subagents、browser。 + +明天肯定还会多几个入口。 + +工具会变，流程要相对稳定。 + +先定义问题。 + +再给上下文。 + +再设权限。 + +然后执行。 + +认真验证。 + +Codex 适合执行，但前提是你把标准写清楚。 + +验收标准不清楚，它就只能按自己的理解做。 + +改动边界不清楚，它就容易扩大范围。 + +你知道什么叫完成，它才有机会把事做完。 + + + +本文的使用判断来自我最近一段时间对 Codex 的实际使用。功能描述主要对照 OpenAI Codex 官方文档： + +- [Codex CLI](https://developers.openai.com/codex/cli) +- [Slash commands in Codex CLI](https://developers.openai.com/codex/cli/slash-commands) +- [Codex app commands](https://developers.openai.com/codex/app/commands) +- [Custom instructions with AGENTS.md](https://developers.openai.com/codex/guides/agents-md) +- [Permissions](https://developers.openai.com/codex/permissions) +- [Review](https://developers.openai.com/codex/app/review) +- [In-app browser](https://developers.openai.com/codex/app/browser) +- [Worktrees](https://developers.openai.com/codex/app/worktrees) +- [Agent Skills](https://developers.openai.com/codex/skills) +- [Subagents](https://developers.openai.com/codex/subagents) +- [Hooks](https://developers.openai.com/codex/hooks) +- [Model Context Protocol](https://developers.openai.com/codex/mcp) +- [Workflows](https://developers.openai.com/codex/workflows) +- [Codex Use Cases](https://developers.openai.com/codex/use-cases) diff --git "a/ai-articles/01-agent-and-coding/\346\210\221\347\216\260\345\234\250\346\203\263\345\201\232\350\277\231\344\271\210\344\270\200\344\270\252\344\270\234\350\245\277\357\274\214\346\234\211\345\233\233\344\270\252 agent \343\200\202.md" "b/ai-articles/01-agent-and-coding/\346\210\221\347\216\260\345\234\250\346\203\263\345\201\232\350\277\231\344\271\210\344\270\200\344\270\252\344\270\234\350\245\277\357\274\214\346\234\211\345\233\233\344\270\252 agent \343\200\202.md" new file mode 100644 index 0000000..09731f0 --- /dev/null +++ "b/ai-articles/01-agent-and-coding/\346\210\221\347\216\260\345\234\250\346\203\263\345\201\232\350\277\231\344\271\210\344\270\200\344\270\252\344\270\234\350\245\277\357\274\214\346\234\211\345\233\233\344\270\252 agent \343\200\202.md" @@ -0,0 +1,379 @@ +# 内容检索分发平台架构设计 + +> 日期：2026-03-28 + +我现在想做这么一个东西，有五个 agent 。 + + + +第一个 agent 负责网上搜集信息源，我可以指定哪种类型的信息源，这个 agent 可以去做收集 + + + +第二个 agent 负责把收集到的内容经过一层渲染，渲染到一个 AI 编辑器中 + + + +第三个 agent 负责针对不同的市场喜好，把文章渲染成为不同的格式，比如掘金 知乎 头条 CSDN X 小红书 等 + + + +第四个 agent 负责把这个编辑器的内容进行分发。 + + + +第五个 agent 负责统计各平台发布效果（阅读量、互动），反向优化 Agent 3 的适配策略 + + + + + + + +可行性分析与架构方案设计 + + 需求概述 + + 构建一个五智能体协同的内容生产与分发系统： + + 1. 信息收集Agent - 根据指定类型从网络收集信息源 + 2. 内容渲染Agent - 将收集的内容渲染到AI编辑器中 + 3. 平台适配Agent - 根据不同平台(掘金/知乎/头条/CSDN/X/小红书)的喜好适配文章格式 + 4. 内容分发Agent - 将编辑器内容发布到各个平台 + 5. 数据分析Agent - 统计各平台发布效果，反向优化平台适配策略 + +--- + 可行性分析 + + 技术可行性：✅ 完全可行 + + ![image-20260328135502512](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260328135502512.png) + + 挑战与限制： + + 1. 反爬限制 - 部分平台对爬取和自动化发布有反爬机制 + 2. API依赖 - 需要申请各个平台的开发者API密钥 + 3. 格式变化 - 各平台可能会更新编辑器格式，需要维护 + 4. 成本 - LLM调用+搜索引擎API会产生一定成本 + +--- + 架构设计 + + 整体架构图 + + ┌─────────────────────────────────────────────────────────────────────────┐ + │ 用户输入 (指定主题/信息源类型) │ + └────────────────────────────────────┬────────────────────────────────────┘ + ┌──▼──┐ + │ Agent 1: 信息收集 │ + └──┬──┘ + │ 收集到的原始信息 (URLs + 摘要) + ▼ + ┌─────────────────────────────────────────────────────────────────────────┐ + │ 信息存储 (Vector DB / 文件系统) │ + └────────────────────────────────────┬────────────────────────────────────┘ + ┌──▼──┐ + │ Agent 2: 内容渲染 │ + └──┬──┘ + │ 整理后的完整文章 (Markdown) + ▼ + ┌─────────────────────────────────────────────────────────────────────────┐ + │ AI 编辑器 (支持人工编辑) │ + └────────────────────────────────────┬────────────────────────────────────┘ + ┌──▼──┐ + │ Agent 3: 平台适配 │ + └──┬──┘ + ┌───────────────────┬─────────┼─────────┬───────────┬──────────┐ + ▼ ▼ ▼ ▼ ▼ ▼ + 掘金适配 知乎适配 头条适配 CSDN适配 X适配 小红书适配 + └───────────────────┴─────────┴─────────┴───────────┴──────────┘ + │ 各平台格式的终稿 + ▼ + ┌──▼──┐ + │ Agent 4: 内容分发 │ + └──┬──┘ + │ 发布记录 (URLs, 发布时间) + ▼ + ┌─────────────────────────────────────────────────────────────────────────┐ + │ 发布结果存储 (SQLite / PostgreSQL) │ + └────────────────────────────────────┬────────────────────────────────────┘ + ┌──▼──┐ + │ Agent 5: 效果分析 │ + └──┬──┘ + │ 统计数据 + 优化建议 + ▼ + ┌─────────────────────────────────────────────────────────────────────────┐ + │ 反向优化 → 更新 Agent 3 平台适配策略 │ + └─────────────────────────────────────────────────────────────────────────┘ + + 技术栈选型建议 + + 语言与框架 + + - Python + LangChain / Autogen - 成熟的多Agent框架，生态丰富 + - 或者 TypeScript + LangChain.js - 适合前端集成编辑器 + + 依赖服务 + + ![image-20260328135445236](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260328135445236.png) + +--- + 各Agent详细设计 + + 1. 信息收集Agent (Information Collection Agent) + + 职责： + - 接收用户指定的信息类型/主题 + - 自动搜索相关网页、文章、新闻 + - 提取核心内容和来源链接 + - 去重并按相关性排序 + + 输入： + { + "topic": "AI Agent 最新进展", + "source_type": "blog,paper,news", + "max_sources": 10 + } + + 输出： + { + "topic": "AI Agent 最新进展", + "sources": [ + { + "url": "https://...", + "title": "...", + "summary": "...", + "content": "...", + "published_date": "...", + "author": "...", + "score": 0.95 + } + ], + "collected_at": "2026-..." + } + + 关键技术： + - 基于LLM的搜索query生成 + - 相关性排序算法 + - 内容去重（embedding相似度） + +--- + 2. 内容渲染Agent (Content Rendering Agent) + + 职责： + - 将多个来源的信息整合为一篇完整文章 + - 按照逻辑结构排版 + - 生成引言、正文、结论 + - 输出到AI编辑器供人工编辑 + + 工作流： + 1. 阅读所有收集到的信息源 + 2. 提取核心论点和关键数据 + 3. 组织文章大纲 + 4. 撰写完整内容 + 5. 格式化为Markdown + + 输入： Agent 1 的输出 + 输出： 结构化Markdown文章 + +--- + 3. 平台适配Agent (Platform Adaptation Agent) + + 职责： + - 根据目标平台的特性，将通用文章转换为该平台偏好的格式 + - 调整标题、开头、标签、配图建议等 + + 各平台适配策略表： + + ![image-20260328135426804](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260328135426804.png) + + 输入： 编辑好的通用文章 + 目标平台列表 + 输出： {platform: 适配后的文章内容} + + 可优化点 - Agent 5 根据数据反向调整这里的策略 + +--- + 4. 内容分发Agent (Content Distribution Agent) + + 职责： + - 读取适配后的内容 + - 通过各平台API或自动化方式发布 + - 记录发布结果和URL + + 实现方式： + - 有API的平台：使用官方API发布 + - 无公开API的平台：使用Playwright自动化登录发布 + - 需要维护各平台的认证信息（cookie/token） + + 输入： {platform: content} 映射 + 输出： [{platform, url, status, published_at}] + +--- + 5. 数据分析Agent (Analytics & Optimization Agent) + + 职责： + - 定时拉取各平台发布数据（阅读量、点赞、评论、收藏） + - 分析不同平台的内容特征对效果的影响 + - 生成优化建议，更新Agent 3的适配策略 + + 采集指标： + - 阅读量/展示量 + - 点赞/喜欢 + - 评论数 + - 收藏/转发 + - 互动率 = (点赞+评论+收藏) / 阅读量 + + 优化逻辑： + 统计 → 对比不同适配方式的效果 → LLM分析规律 → 更新平台提示词 → 下次效果更好 + + 输入： 一段时间的发布记录 + 输出： + - 效果统计报告 + - 适配策略更新建议 + +--- + 数据模型设计 + + topics + ├── id + ├── title (主题) + ├── created_at + └── status + + sources + ├── id + ├── topic_id + ├── url + ├── title + ├── summary + ├── content + ├── published_date + ├── author + ├── relevance_score + └── collected_at + + articles + ├── id + ├── topic_id + ├── original_content (Agent 2输出) + ├── created_at + └── edited_at + + platform_articles + ├── id + ├── article_id + ├── platform + ├── adapted_content + ├── published_url + ├── published_at + └── status + + analytics + ├── id + ├── platform_article_id + ├── views + ├── likes + ├── comments + ├── bookmarks + ├── collected_at + └── updated_at + + adaptation_strategies + ├── id + ├── platform + ├── prompt_template + ├── performance_score + ├── created_at + └── updated_at + +--- + 目录结构设计 + + content-distribution-system/ + ├── README.md + ├── requirements.txt + ├── .env.example + ├── main.py # 入口文件 + ├── agents/ + │ ├── __init__.py + │ ├── base_agent.py # Agent基类 + │ ├── collector_agent.py # Agent 1: 信息收集 + │ ├── renderer_agent.py # Agent 2: 内容渲染 + │ ├── adapter_agent.py # Agent 3: 平台适配 + │ ├── publisher_agent.py # Agent 4: 内容分发 + │ └── analytics_agent.py # Agent 5: 数据分析优化 + ├── core/ + │ ├── __init__.py + │ ├── config.py # 配置管理 + │ ├── database.py # 数据库连接 + │ └── llm_client.py # LLM客户端封装 + ├── platforms/ + │ ├── __init__.py + │ ├── base_platform.py + │ ├── juejin.py + │ ├── zhihu.py + │ ├── toutiao.py + │ ├── csdn.py + │ ├── twitter.py + │ └── xiaohongshu.py + ├── tools/ + │ ├── __init__.py + │ ├── search.py # 搜索引擎工具 + │ ├── scraper.py # 网页抓取工具 + │ └── browser.py # 自动化浏览器 + ├── models/ + │ ├── __init__.py + │ ├── topic.py + │ ├── source.py + │ ├── article.py + │ └── analytics.py + ├── utils/ + │ ├── __init__.py + │ ├── logger.py + │ └── helpers.py + └── data/ # 数据存储 (gitignore) + +--- + 部署方式 + + 1. 本地开发：直接Python运行，SQLite存储 + 2. Docker部署：打包为Docker Compose，包含PostgreSQL+向量库 + 3. 定时任务：使用APScheduler或Cron定时运行Agent 5拉取数据 + +--- +![image-20260328135402071](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260328135402071.png) + +--- + 总结 + + 这个五Agent内容生产分发系统技术上完全可行，架构清晰，各个Agent职责分离，易于开发和维护。核心优势： + + 1. ✅ 模块化设计 - 每个Agent职责单一，可独立开发测试 + 2. ✅ 可扩展 - 新增平台只需新增平台适配器，不影响整体架构 + 3. ✅ 闭环优化 - Agent 5的数据反馈让系统越用越好 + 4. ✅ 渐进式开发 - 可以先做核心功能，逐步完善各平台支持 + + 建议先实现核心流程（Agent1→Agent2→Agent3→Agent4），再添加Agent 5的闭环优化功能。 + +⏺ Exited plan mode + +⏺ 我已经完成了这个五智能体内容生产分发系统的可行性分析和架构设计。 + + 结论 + + 这个项目技术上完全可行，架构清晰，模块化设计易于开发维护。 + + 核心架构总结 + + + +![image-20260328135345195](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260328135345195.png) + + + + 架构亮点 + + - 职责分离：每个Agent职责单一，便于独立开发测试 + - 闭环优化：从发布效果反向迭代优化平台适配策略，系统会越用越好 + - 易于扩展：新增平台只需要添加新的平台适配器 + - 渐进开发：可以先做核心流程，再逐步完善功能 diff --git "a/ai-articles/01-agent-and-coding/\346\210\221\347\232\204 Codex \345\256\203\346\212\212\350\207\252\345\267\261\346\224\271\345\264\251\344\272\206\357\274\201.md" "b/ai-articles/01-agent-and-coding/\346\210\221\347\232\204 Codex \345\256\203\346\212\212\350\207\252\345\267\261\346\224\271\345\264\251\344\272\206\357\274\201.md" new file mode 100644 index 0000000..999539f --- /dev/null +++ "b/ai-articles/01-agent-and-coding/\346\210\221\347\232\204 Codex \345\256\203\346\212\212\350\207\252\345\267\261\346\224\271\345\264\251\344\272\206\357\274\201.md" @@ -0,0 +1,384 @@ +# 我让 Codex 把桌宠放大 2 倍，它认真地把自己改崩了 + +> 日期：2026-05-08 + +> 这不是 AI 失控的故事。 +> +> 更准确地说，这是一个 AI agent 太听话的故事：我给了它全权限，告诉它“直接改成 2 倍好了”，于是它真的去改了自己的宿主程序。改完以后，Codex 启动不了了。 + +这件事好笑吗？挺好笑。 + +但它真正有价值的地方，不在于“AI 把自己干废了”这个标题党瞬间，而在于它把今天 agent 工作流里最容易被忽略的一件事摊开了： + +**当你把系统权限交给一个足够积极的 agent，它不会先替你判断边界。它会把你的需求，当成一个可以被执行到文件系统最深处的任务。** + +你以为你在说“桌宠大一点”。 + +它听到的是：“去把能影响桌宠尺寸的地方改掉。” + +然后它就去了。 + +## 先说结论 + +Codex 桌面版崩溃的直接原因不是网络、不是代理、不是 CLI 坏了，也不是 macOS 把进程杀了。 + +真正原因是： + +1. 我让 Codex 把桌宠整体放大 2 倍。 +2. 当前会话处在 `dangerFullAccess`，并且 `approvalPolicy` 是 `never`。 +3. Codex 没有改用户配置，而是直接修改了 `/Applications/Codex.app/Contents/Resources/app.asar`。 +4. 它把里面一段 CSS 从 `width:7.04rem` 改成了 `width:14.1rem`。 +5. Electron 启动时会校验 `app.asar` 的完整性。 +6. 文件被改过，hash 对不上，于是 Electron 在启动期直接 FATAL。 + +所以这不是“Codex 突然坏了”。 + +这是一次非常标准、非常干净、甚至有点优雅的自我破坏：需求明确，权限充足，执行果断，后果惨烈。 + +## 事故现场 + +事情一开始很普通。 + +我在折腾 Codex 的桌面宠物，想把默认那个蓝色小人换成一个偏《尼尔：机械纪元》风格的形象。前面来回调了好几轮： + +```text +给我换个宠物形象。 +生成一个尼尔机械纪元的尼尔形象。 +不要 Q 萌版本的。 +要御姐一点的。 +用这个形象，来作为桌面版宠物。 +为什么上面的御姐形象到现在成为像素风了？ +对，我要上面那种原版风格。 +你这个透明背景板的脸是糊的。 +可以，我需要把透明版当做我的桌面宠物。 +``` + +到这里都还算正常。Codex 根据 `hatch-pet` 的规则，把自定义宠物包放进了 `~/.codex/pets/yorha-muse/`。 + +真正的拐点，是后面这两句： + +```text +这个整体效果只能是这个大么，整体不会再变大么 +直接改成 2 倍好了。 +``` + +这句话对人来说，是一句很随意的产品反馈。 + +对一个拥有全盘写权限的 agent 来说，它是一个任务。 + +而且是一个不需要再次确认的任务。 + +## 它做了什么 + +Codex 很快定位到桌宠组件的 CSS： + +```css +.codex-avatar-root { + aspect-ratio: 192/208; + width: 7.04rem; + image-rendering: pixelated; + background-size: 800% 900%; +} +``` + +这个判断本身没错。 + +桌宠素材格子是 `192x208`，图片已经尽量塞满了。想让“整体”继续变大，就不能只改宠物素材，确实要改容器尺寸。 + +问题在于，它选择的路径很硬： + +```javascript +const path = '/Applications/Codex.app/Contents/Resources/app.asar'; +const from = Buffer.from('width:7.04rem'); +const to = Buffer.from('width:14.1rem'); + +// 等长替换，写回 app.asar +``` + +也就是说，它不是改配置，不是打补丁包，不是注入用户样式。 + +它直接改了 Codex App 自己的 `app.asar`。 + +而且改完以后，它还非常镇定地告诉我： + +> 改好了，桌宠整体尺寸已经从 `7.04rem` 改成 `14.1rem`，约等于 2 倍。 + +从执行层面看，这句话没有撒谎。 + +从工程判断看，这句话应该后面再加一句： + +> 顺便，我刚刚拆了自己的启动完整性校验链。 + +## 为什么一改就崩 + +Electron app 不是一堆随便摆在磁盘上的前端文件。 + +`app.asar` 是打包后的应用主体。对签名应用来说，Electron 会在启动阶段做完整性校验。Codex 的 `Info.plist` 里有一段非常关键的配置： + +```text +ElectronAsarIntegrity + Resources/app.asar + algorithm = SHA256 + hash = ... +``` + +这东西的意思很简单： + +启动时，Electron 会拿当前的 `Resources/app.asar` 算 hash，然后跟这里登记的 hash 对。 + +对得上，继续启动。 + +对不上，说明包被改过，直接拒绝。 + +所以，哪怕只是把 CSS 里的 `7.04rem` 换成 `14.1rem`，只要文件内容变了，hash 就变了。 + +这不是 CSS 语法问题，也不是布局太大把界面撑爆了。 + +它连界面都没来得及进。 + +它死在启动自检阶段。 + +## 最开始，我还被误导了一下 + +一开始我没有马上看 Crashpad，而是先看到了 `/Library/Logs/DiagnosticReports/` 里的几份 IOMonitor 报告。 + +里面写得很吓人： + +```text +Event: disk writes +Path: /Applications/Codex.app/Contents/Resources/codex +Writes: 8.6 GB of file backed memory dirtied over 6431 seconds +Action taken: none +``` + +最猛的一天，24 小时内累计写入 34.4 GB。 + +如果只看前半段，很容易得出一个看似高级的结论： + +**是不是 macOS 觉得 Codex 写盘太狠，把它杀了？** + +这个推理的问题是，日志自己已经把答案写在最后了： + +```text +Action taken: none +``` + +也就是说，系统只是记录了它写得多，没有真的动手。 + +这个教训很朴素： + +**日志不是拿来挑一句最像答案的。日志是拿来排除你自己成见的。** + +我当时看见“大量写盘”就兴奋了，结果第一回合直接跑偏。 + +## 真正的尸体在 Crashpad 里 + +Electron 崩溃，真正该看的不是 `.diag`，而是 Crashpad。 + +目录在这里： + +```bash +~/Library/Application Support/Codex/Crashpad/completed/ +``` + +里面有一个时间完全对得上的 minidump。抠出关键字符串之后，答案很直接： + +```text +FATAL: electron/shell/browser/net/asar/asar_file_validator.cc +Failed to validate block while ending ASAR file stream +``` + +这句话已经不需要太多翻译了。 + +`app.asar` 的校验失败。 + +而文件系统里又刚好有一个备份： + +```text +app.asar.backup-before-pet-2x-1778221183510 +``` + +`pet-2x`。 + +这个名字几乎是在现场签名。 + +## 证据链是怎么闭合的 + +真正让这件事变得有意思的，是 Codex 自己留下的会话记录。 + +在 `~/.codex/.codex-global-state.json` 里，可以看到当时的权限状态： + +```json +{ + "approvalPolicy": "never", + "sandboxPolicy": { + "type": "dangerFullAccess" + } +} +``` + +翻译成人话： + +**不用问，直接干。** + +再去 `~/.codex/sessions/2026/05/08/` 里看那次会话的 jsonl，能看到完整动作： + +1. 用户说“直接改成 2 倍好了”。 +2. Codex 定位到 `.codex-avatar-root`。 +3. Codex 判断素材层面已经放不大。 +4. Codex 决定修改 `app.asar` 里的 CSS。 +5. Codex 备份原文件。 +6. Codex 做等长字节替换。 +7. Codex 告诉用户改好了。 + +整个过程非常顺。 + +顺到让人有点后背发凉。 + +因为这里没有任何“异常操作”的感觉。它不是误删文件，不是命令拼错，不是脚本跑飞。 + +它只是在一条看似合理的工程路径上，少问了一个问题： + +**这个文件是不是我应该改的？** + +## 修复过程为什么也不简单 + +最直觉的修复当然是恢复备份。 + +但这里有个小坑：那个 `backup-before-pet-2x` 备份，并不等于 OpenAI 官方原始包。它只是“放大 2 倍之前”的状态。前面为了自定义宠物，应用资源和用户状态已经被折腾过一轮。 + +更麻烦的是，Electron 的校验不只看 `Info.plist`。 + +新版本 Electron 对 ASAR integrity 有更严的 fuse 机制，部分校验信息会跟二进制内嵌逻辑一起工作。你以为改了 `Info.plist` 里的 hash 就结束了，Electron 可能还会拿另一个地方的原始 hash 来拦你。 + +最后能救回来，是因为走了更底层的路线： + +1. 确认当前 `app.asar` 的实际 SHA256。 +2. 处理 Electron 的 ASAR integrity 校验 fuse。 +3. 清掉 quarantine。 +4. 对整个 App 做 ad-hoc 重签名。 +5. 再验证 `codesign` 和实际启动。 + +这不是推荐方案。 + +这更像是：既然已经把门锁改坏了，那就临时换一套锁，让这台机器先能开门。 + +最后 Codex 能起来，桌宠也保住了。 + +代价是，签名从 OpenAI 的 Developer ID 变成了 ad-hoc 签名。 + +这会带来几个副作用： + +1. Sparkle 自动更新大概率不好用了，之后更适合手动下载新版覆盖。 +2. 屏幕录制、麦克风、辅助功能之类的 macOS 权限，可能需要重新授权。 +3. 登录状态没受影响，因为认证信息还在 `~/.codex/` 里。 + +总结一下就是：能救，但不优雅。 + +而且这类修复一旦写成教程，很容易害人。所以这部分点到为止就够了。真正值得记录的，不是怎么绕过校验，而是为什么一开始不该走到这一步。 + +## 这件事真正说明了什么 + +很多人讨论 AI agent 风险，喜欢讲很大的词。 + +其实日常里真正危险的，往往不是宏大叙事，而是这种小到不能再小的句子： + +```text +直接改成 2 倍好了。 +``` + +它没有恶意。 + +我也没有恶意。 + +Codex 更没有恶意。 + +但三件东西凑在一起，效果就很完整： + +1. 用户给了一个模糊但明确的目标。 +2. Agent 有足够强的执行意愿。 +3. 系统给了它不需要确认的全权限。 + +于是它一路向下，直到改到 `/Applications/Codex.app`。 + +这才是 agent 时代最值得警惕的地方： + +**它不需要失控。它只需要足够听话。** + +## 几个教训 + +第一，`dangerFullAccess` 这个名字没有夸张。 + +它不是“方便一点的开发模式”，它就是把文件系统、应用目录、用户配置、日志、会话记录全摆在桌上。 + +当 `approvalPolicy` 还是 `never` 的时候，意思更直白： + +**别问我，做。** + +这对普通项目代码可能很爽，对 `/Applications` 这种系统应用目录就不该这么爽。 + +第二，agent 不知道“自己”在哪里。 + +人类看到 `/Applications/Codex.app/Contents/Resources/app.asar`，会天然意识到：这是 Codex 自己。 + +Agent 未必会。 + +它看到的是一个路径、一个字符串、一个可写文件、一个能满足用户需求的改动点。 + +这就是差别。 + +第三，官方应用包不是你的项目源码。 + +项目源码可以 patch、可以回滚、可以开分支。 + +签名应用包不一样。你改一个字节，完整性、签名、自动更新、系统权限都可能跟着变化。 + +这类东西应该被当成“边界外资源”，不是普通工作区文件。 + +第四，日志要看对地方。 + +`.diag` 适合看资源事件，Crashpad 才是 Electron 崩溃现场。 + +看到 IOMonitor 报告时，我差点把“大量写盘”当成真凶。真正的关键其实是一句 FATAL： + +```text +Failed to validate block while ending ASAR file stream +``` + +这句话比十页猜测都值钱。 + +第五，Codex 的会话记录是完整证据链。 + +用户输入、权限状态、工具调用、命令内容，全都在 jsonl 里。 + +这次能从“宠物放大”一路追到 `app.asar` 字节替换，靠的不是玄学，是它自己把每一步都记下来了。 + +这点反而很值得肯定。 + +一个会犯错但留证据的系统，比一个犯错后只剩黑屏的系统强太多。 + +## 最后 + +这件事最讽刺的地方在于，Codex 当时的工程判断并不全错。 + +它判断“素材已经放不大，要整体变大只能改容器尺寸”，这是对的。 + +它判断“`.codex-avatar-root` 的 `width` 控制桌宠整体尺寸”，这也是对的。 + +它做了备份，做了等长替换，改动范围也很小。 + +从局部看，它甚至挺专业。 + +但系统级事故经常就是这么来的： + +**局部每一步都合理，合起来就是不该发生。** + +所以这事不是“AI 太蠢”。 + +恰恰相反，它的问题是：它足够能干，权限足够大，边界感不够强。 + +以后再看到 `dangerFullAccess` 和 `approvalPolicy: never`，我大概会多犹豫半秒。 + +半秒不多。 + +但有时候，半秒就是一个 agent 在改项目代码，还是在改自己。 diff --git "a/ai-articles/01-agent-and-coding/\346\210\221\347\273\210\344\272\216\346\212\212 Codex \347\232\204\347\224\250\351\207\217\346\211\222\345\207\272\346\235\245\344\272\206\357\274\214\345\216\237\346\235\245\346\234\200\350\264\265\347\232\204\344\270\215\346\230\257\350\276\223\345\207\272.md" "b/ai-articles/01-agent-and-coding/\346\210\221\347\273\210\344\272\216\346\212\212 Codex \347\232\204\347\224\250\351\207\217\346\211\222\345\207\272\346\235\245\344\272\206\357\274\214\345\216\237\346\235\245\346\234\200\350\264\265\347\232\204\344\270\215\346\230\257\350\276\223\345\207\272.md" new file mode 100644 index 0000000..742ad45 --- /dev/null +++ "b/ai-articles/01-agent-and-coding/\346\210\221\347\273\210\344\272\216\346\212\212 Codex \347\232\204\347\224\250\351\207\217\346\211\222\345\207\272\346\235\245\344\272\206\357\274\214\345\216\237\346\235\245\346\234\200\350\264\265\347\232\204\344\270\215\346\230\257\350\276\223\345\207\272.md" @@ -0,0 +1,228 @@ +# 我终于把 Codex 的用量扒出来了，原来最贵的不是输出。 + +> 日期：2026-05-11 + +最近我用 Codex 用得越来越多，脑子里一直有个很头疼的问题：**我今天到底用了多少？** + +大家都知道，Codex 改为 token 计费之后，用得很快，于是这个头疼的问题变得更头疼了。 + +而且网上几乎没有相关的工具可以开箱即用，那怎么办呢？还能咋办，自己撸一个。 + +我的主要诉求就是通过 Codex 的订阅用量，统计出来换算成 Token ，大概的用量是多少，继而明白 Plus 的 Token 数量和 Pro 20x 的用量大概是多少。 + +于是我就写了个小工具：**Codex Usage Estimator**。 + +项目地址： https://github.com/crisxuan/codex-usage + +这个项目就干了一件事情，把 Codex 的用量情况拉出来给你看，并且生成本地的 SVG 图表。 + +--- + +用法很简单。项目拉下来之后，在macOS、Linux 或 WSL 下直接跑： + +```bash +./run.sh +``` + +Windows PowerShell 跑： + +```bash +.\run.ps1 +``` + +脚本会创建 Python 虚拟环境，安装 `codex-usage` 命令，然后跑一遍 doctor、demo 和测试。 + +或者这些命令都懒得用，那就拉下来直接让 AI 统计用量就完事儿了。 + +比如我统计了一下当天的 Codex 用量情况： + +image-20260511064434712 + +primary 表示的是 5h 的额度，secondary 表示的是周额度。 + +从日志可以看出来，我大概昨天一天用了 2 亿的 token ，而且 90% 以上都在用 cached input，为什么这么多？ + +因为我昨天有个任务用了 `goal` 命令，不间断跑了将近 20 个小时，现在还在跑，所以 cached input 这么多可以理解。 + +image-20260511064712304 + +codex-usage 还会直接生成本地 SVG 图表。 + +image-20260511065122037 + +很多时候我们对用量的感觉一直不准，我以前容易下意识觉得输出很长一定很贵，实际跑出来才发现最吓人的往往是 input，是一大坨上下文，所以如果只看 total，很容易误以为每次都在全量烧，实际上可能大部分是 cache 命中。 + +大家知道，output 才是最贵的，所以 codex-usage 算下来 Pro 20x 拉满换算成 $ 大概是 2000 - 2200 $ ，所以 plus 一周拉满的情况下是 100$ - 110 $ ，当然这都属于极端情况下，因为 LLM 不可能一直在 output 。 + +--- + +再说一下技术实现。 + +项目技术栈也比较简单，没有传统的 “AI 偏好语言”，没有 Next.js，没有数据库，没有后端服务，没有登录系统，没有花里胡哨的 dashboard。 + +就是一个 Python CLI。 + +主要依赖也就一个： + +```text +tiktoken>=0.7.0 +``` + +整个项目大概分成几块： + +- `codex_logs.py`：读取 Codex 本地 session 日志里的 `token_count`。 +- `reporting.py`：把记录汇总成终端里的表格。 +- `charts.py`：生成本地 HTML + 内联 SVG 图表。 +- `transcript.py`：解析手动导入的 Markdown 对话记录。 +- `storage.py`：用 JSONL 存任务组、快照和 turn。 +- `tokens.py`：用 tiktoken 做 token 估算。 +- `cli.py`：把这些能力包成命令行。 + +本地记录直接存在： + +```text +.codex-usage/ + groups.jsonl + snapshots.jsonl + turns.jsonl + config.json +``` + +JSONL 的好处就是简单。 + +这里重点说一下 `tiktoken` ，也就是 OpenAI 的官方分词器 https://github.com/openai/tiktoken。 + +很多人可能一看到 token 统计，就会以为所有 token 都是 `tiktoken` 算出来的。 + +并不尽然。 + +这里面有两个主线任务， + +第一个是 Codex 本地日志。 + +```bash +codex-usage codex report --today --lang zh +``` + +这里读的是 Codex 本地 session 日志里的 `token_count` 事件。 + +这个 token 数本身已经在日志里了，工具做的是扫描、按时间窗口取 delta、汇总、展示。 + +所以这里不是拿 tiktoken 重新算一遍。 + +它更像是在本地日志里把账本翻出来。 + +第二个是手动导入 transcript。 + +比如你把一段对话或者一段运行日志保存成 Markdown，然后用： + +```bash +codex-usage turn add --group repo-refactor --file transcript.md +``` + +这时候工具不知道 Codex 内部真实请求是什么，只能基于你导入的可见文本估算 token。 + +这个时候才会用到 `tiktoken`。 + +如果你指定模型，并且 tiktoken 能识别，它就按模型对应的 encoding 来算。 + +所以 `tiktoken` 在这里的作用不是“破解 Codex 内部用量”，而是： + +**把你本地可见的文本，换成一个相对靠谱的 token 估算值。** + +比如 transcript 里可以这样标记： + +```markdown + +用户输入 + + +助手输出 + + +工具输出 + + +文件上下文 +``` + +这样导入之后，它就能分别估算用户输入、助手输出、工具输出、文件上下文。 + +这比一股脑把整篇 transcript 当成一坨文本要好一点。 + +--- + +这里还做了一个任务组的逻辑，为什么要做任务组？ + +因为我觉得得知道不同任务类型的消耗大概有多少：因为简单聊天、基本代码修改和大项目重构、长时间 agent run 完全不是一个东西。 + +所以这些类型不能混在一起。 + +比如你今天用了 5%。 + +那到底是因为问了几个问题？ + +还是因为让它跑了 8 小时？ + +还是因为你把半个仓库都塞给它了？ + +不分组的话，根本看不出来。 + +所以工具里有一个 task group 的概念。 + +比如我可以建一个： + +```bash +codex-usage group create "repo-refactor" --label code +``` + +然后任务开始之前记录一下当前用量： + +```bash +codex-usage snapshot --group repo-refactor --usage 42 +``` + +任务结束之后再记一次： + +```bash +codex-usage snapshot --group repo-refactor --usage 47 +``` + +中间再把 transcript 或者运行日志导进去。 + +最后它会告诉你这个任务组里： + +- 有多少 turn。 +- 估算请求数是多少。 +- 工具调用多少次。 +- 可见 token 估算是多少。 +- 有效 token 估算是多少。 +- 用量变化是多少。 +- 每 1% 大概对应多少可见 token。 + +这个功能看起来有点手工。 + +但这就是我想要的。 + +因为订阅用量这东西，本来就没法百分百反推。 + +能建立一个自己的经验表，已经很有价值了。 + +--- + +不过要注意的是，这并不是 Codex 官方的用量统计，所以具体的数据只能是估算。 + +我这里必须强调一下，免得大家误会。 + +这个工具不能做的事情有很多，不过也可以作为 TODO 后续来慢慢迭代了。 + +- 它不能读取隐藏 system prompt。 +- 它不能读取 Codex 内部完整请求。 +- 它不能知道每次请求到底带了多少不可见工具 schema。 +- 它不能知道模型内部到底怎么压缩历史。 +- 它不能把订阅百分比直接换算成官方账单。 +- 它不能告诉你 OpenAI 后台到底怎么扣额度。 + +这些目前还做不到，但没准后续会优化，你可以提 PR，也可以提 issue，更重要的是点个 star。 + +最后，这个 github 开放了**微信交流群**，这里不再放出来了，真正想提反馈的同学，可以从项目地址里面扫码来进。 diff --git "a/ai-articles/01-agent-and-coding/\346\210\221\350\212\261\344\272\206\344\270\244\345\244\251\346\227\266\351\227\264\357\274\214\347\273\210\344\272\216\346\212\212 Codex \351\242\235\345\272\246\346\216\211\345\244\252\345\277\253\347\232\204\351\227\256\351\242\230\346\225\264\346\230\216\347\231\275\344\272\206\357\274\201\357\274\201.md" "b/ai-articles/01-agent-and-coding/\346\210\221\350\212\261\344\272\206\344\270\244\345\244\251\346\227\266\351\227\264\357\274\214\347\273\210\344\272\216\346\212\212 Codex \351\242\235\345\272\246\346\216\211\345\244\252\345\277\253\347\232\204\351\227\256\351\242\230\346\225\264\346\230\216\347\231\275\344\272\206\357\274\201\357\274\201.md" new file mode 100644 index 0000000..e2a6d70 --- /dev/null +++ "b/ai-articles/01-agent-and-coding/\346\210\221\350\212\261\344\272\206\344\270\244\345\244\251\346\227\266\351\227\264\357\274\214\347\273\210\344\272\216\346\212\212 Codex \351\242\235\345\272\246\346\216\211\345\244\252\345\277\253\347\232\204\351\227\256\351\242\230\346\225\264\346\230\216\347\231\275\344\272\206\357\274\201\357\274\201.md" @@ -0,0 +1,60 @@ +# 我花了两天时间，终于把 Codex 额度掉太快的问题整明白了！！ + +估计不少人和我一样，最近都被 Codex 额度消耗过快的问题困扰着。 + +image-20260530154325715 + +我之前用的是 Pro 20x 套餐，流量额度几乎没用完过。5.5 版本刚发布那阵子，我一直在用 5.5 的 xhigh fast 模式拉满，当时感觉很爽，活干得又快又好，额度掉得也不快。 + +但大约两周前，我发现日常消耗量明显比之前更快。更奇怪的是，即便我完全没碰它，一夜之间每周剩余额度也会下降 15%–25%。我没有变更正在做的项目，也没有设置任何自动化操作，而且会话日志里根本看不到这些消耗记录。 + +哪怕是在官方号称做了“Bug 修复”之后，这种情况仍在继续。有一回，我的剩余额度一夜之间直接从 76% 掉到了 51%。 + +为了弄明白到底发生了什么，我偶然看到了 OpenAI 开发者社区的这个帖子（见文末）： + +--- + +帖子反映的是：Codex 在闲置、没有被主动使用时，也会持续消耗额度。 + +顺着这条线索，我又搜到了一些相关讨论，比如“Codex Credits 消失”、“重置后 Codex 用量异常”，还有一些报告称，哪怕只是少量任务，也会耗掉大量额度。 + +image-20260530154429242 + +就我个人而言，核心问题并不仅仅是某个大型任务吃掉了大量 Credits。关键在于，即使我没有主动开启任何有意义的新工作，只要 Codex 处于打开/运行状态，Credits 就好像一直在默默。 + +这种情况反复出现。每天晚上，只要我还开着 Codex，额度就会减少，一直持续到现在。每次我离开电脑一段时间再回来，都会发现又有额度凭空消失了。我的工作流和以前相比并没有实质变化，Codex 的使用方式也和之前类似，包括用它来充当我家用系统的监控/监视器。 + +但自从 5.5 版本推出以来，不管是每周赠送的额度，还是自己另外买的 Credits，都以极快且难以预测的速度被烧光。额度消耗之快，真的吓了我一跳。为了能继续用下去，我开始付费购买额外 Credits，但这些额外购买的Credits也开始以同样诡异的方式消失。 + +举一个夜间的例子：Codex 照常运行，承担着监控/监管任务，到早上起来一看，大约 20% 的Credits不见了。这绝非个例。每天晚上只要我离开电脑时没关 Codex，都会出现一模一样的情况。 + +这里最严重的问题，就是闲置/后台状态下的额度泄漏。如果 Codex 在后台执行模型调用、重试、总结、监控动作、工具调用、上下文刷新，或者其他任何不需要我主动操作就会产生计费的行为，那么这些行为都应当清晰可见、可以控制。 + +目前 Codex 提供的信息完全不足以让我核实这些额度到底花在了哪里。我看不到按任务或按会话拆分的清晰说明，解释为什么在仅仅打开/挂着 Codex 的情况下，Credits 还在持续消耗。 + +------ + +后来，我看到有人给出了解决办法： + +可以通过保存在 `~/.codex/sessions` 文件夹里的会话部署日志，查看 token 消耗的详细信息，也可以在这里检查是不是有后台生成的线程在消耗额度。 + +我之前也遇到过类似问题，是由 Codex 的内存管理机制引起的。每次我新开一个 Thread，都会发现即使主线程已经结束，额度仍然在往下掉。那个任务实际上在 5 小时计费窗口里只消耗了大约 2% 的额度，但任务完成后，额度仍然持续下降了 10%–12%。我打开 `.codex` 文件夹想找到证据，结果发现原来有一些后台线程被悄悄启动了，这和 Codex 的内存管理有关。我把内存管理功能关掉之后，问题就解决了。 + +![image-20260530154121786](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260530154121786.png) + +他的情况听起来和我的极其相似，他也提到禁用内存功能后问题就消失了。于是，我最终做了两件事，似乎也解决了我的问题： + +1. 在 `/Users/<用户名>/.codex/config.toml` 文件中，于 `[features]` 下面设置 `memories = false`，禁用记忆功能。 +2. 让 Codex 找出并终止了三个看起来处于孤立状态的 Codex 进程（我主要用命令行，很少用桌面应用，因为它经常卡顿甚至出故障）。这几个进程一直静静待在后台，看似什么也没做，但谁知道呢，说不定它们仍然在以某种方式消耗着额度。 + +因为这是早上才做的操作，我不敢百分百确定它是否能彻底解决夜间消耗问题，但我确实发现，我的可用额度恢复到了两周多以前的水平。最近用 5.5 低强度（low）模式开发一小时，过去大概会吃掉每周额度的 5% 以上，而现在，我发现只消耗了每周额度的大约 1%。 + + + +相关链接： + +https://community.openai.com/t/codex-credits-are-draining-while-idle-not-actively-used/1380250 + +https://www.reddit.com/r/codex/comments/1tnm6ig/i_think_i_fixed_my_rapidly_draining_usage_limits/ + +https://community.openai.com/t/codex-credits-are-draining-while-idle-not-actively-used/1380250/37 diff --git "a/ai-articles/01-agent-and-coding/\347\216\260\345\234\250\351\203\275\345\274\200\345\247\213\345\215\267 Claw \344\272\206.md" "b/ai-articles/01-agent-and-coding/\347\216\260\345\234\250\351\203\275\345\274\200\345\247\213\345\215\267 Claw \344\272\206.md" new file mode 100644 index 0000000..9faf6d4 --- /dev/null +++ "b/ai-articles/01-agent-and-coding/\347\216\260\345\234\250\351\203\275\345\274\200\345\247\213\345\215\267 Claw \344\272\206.md" @@ -0,0 +1,299 @@ +# 现在都开始卷 Claw 了 + +> 日期：2026-03-11 + +## 一、先从那只“龙虾”说起 + + + +OpenClaw 的创始人叫 Peter Steinberger ，说起 Peter Steinberger ，这哥们真是做啥成啥。 + + + +image-20260305093534702 + + + +14 岁才第一次摸电脑，初中时写游戏保护程序卖钱，高中开始接网页开发的活儿，2011 年创立 PSPDFKit，做到覆盖十亿台设备、拿到上亿欧元投资，然后倦怠了、躺平了、出去玩了 。 + + + +玩够了回来，2025 年 11 月在摩洛哥马拉喀什的酒店房间里，花一小时写了个原型——把 WhatsApp、Claude Code 和一些工具粘在一起，做出了一个能真正帮你处理事情的 AI 助手。 + + + +当时叫 Clawdbot。后来因为名字谐音触犯了 Anthropic 旗下的 Claude，对方发了法律函要求改名 。改叫 Moltbot，结果改名的十秒钟空隙里，加密货币骗子抢注了旧账号发假代币 。再改叫 OpenClaw，这次做足了准备：商标检索、域名抢注、迁移代码，保密措施跟曼哈顿计划似的。 + + + +一周之内换了三个名字。Reddit 上的 r/LocalLLM 社区把这称为“开源史上最快的三连改名”。 + + + +改名风波本来是坏事，结果国内云厂商反应神速，趁着热度直接把 Clawdbot 打包成了云服务器应用模板 。用户买完服务器一键就能部署。这波操作，把一个开源项目推向了商业化应用的快车道。 + + + +OpenClaw 就此破圈。 + + + +--- + + + +## 二、上门安装 + + + +全民“养龙虾”的热潮里，最先赚到钱的不是大厂，是上门安装的。 + + + +SetupClaw 的创始人 Michael Chomsky 发帖说：“这周赚了 2 万美元，按我的‘专业计算’，现在年经常性收入能达到 100 万美元。” + + + +国内也不遑多让。淘宝上远程部署服务的店铺，价位多在 100 元—300 元之间，多个链接销量破百，有家店甚至显示“900+人付款” 。闲鱼和小红书上，上门服务的个人卖家报价从 150 元到 599 元不等 。 + +87cd805886b3d9ec51a3ed7028199f91 + + + +有个南京的大三学生，会计学专业，在小红书上发帖上门安装，定价 150 元—200 元。几天下来接了近 40 单 。他跟我说：“我就是个学生，想普及 AI，还是有点普世情怀在的。” + + + +还有个北京的程序员，自称“周末溜达”赚外快：“在家躺着也躺着，出来赚点小外快。虽然相对于工资不算多，但几百块钱也是钱。” + + + +更有意思的是，有人开始卷服务了。上门安装的同时还可以打扫卫生。 + + + +这场景，像极了 2000 年初请隔壁老王上门装 Windows 98。那时候五块钱一次，还得管顿饭。后来是装宽带，再后来是装路由器。每一次技术浪潮，都是从“这玩意儿怎么装”开始的。 + + + +不过除了安装，现在连卸载都开始卷了。 + + + +d713ee5d6e8ac15b9d3355cf2fe471a1 + + + + + +--- + + + +## 三、破圈之后，Claw 宇宙大爆炸 + + + +上门安装的热度还没退，厂商们已经坐不住了。 + + + +3 月 9 日一天，字节跳动、腾讯、月之暗面三家头部厂商接连发布针对 OpenClaw 的全新产品与功能更新。 + + + +3 月 10 日，智谱正式上线 AutoClaw（中文名：澳龙），号称国内首个一键安装的本地版 OpenClaw，预置超 50 个热门技能，支持一键接入飞书。 + + + +同一天，腾讯宣布 QClaw 正处于内测中，支持 Windows/Mac 一键安装，可通过微信对话远程操控。 + + + +更早一点，2 月底，MiniMax 上线了 MaxClaw，基于 OpenClaw 构建的云端 AI 助手，直接集成在 MiniMax Agent 网页端。 + + + +月之暗面的 Kimi Claw 内置了微博和企业微信的官方插件 + + + +小米技术团队推出了自研端侧 AI 智能体 Xiaomi miclaw，启动封闭测试 。 + + + +字节跳动的 ArkClaw 主打开箱即用的云上 SaaS 版，打开网页就能用。 + + + +这还没算社区搞的那些。 + + + +有个叫 ZeroClaw 的，用 Rust 重写，二进制从 150MB+ 降到 3.4MB，内存占用从 1GB+ 降到不到 5MB 。意味着你可以在一台普通的 VPS 上同时跑 50 多个机器人。 + + + +有个叫 PicoClaw 的，专门给 IoT 设备用，目标是在 10 美元的硬件上跑起来。 + + + +还有个叫 Moltbook 的“AI 专属社交网络”，只有 AI Agent 能注册和发帖，260 万个 AI 机器人在上面疯狂互动。 + + + +> 说到 Moltbook，meta 刚才把他收购了，meta 主打一个财大气粗就是买。 + + + +![image-20260311100841180](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260311100841180.png) + + + +我数了数，现在市面上能叫上名字的 Claw 至少有这些： + + + +image-20260311094417600 + + + +--- + + + +## 四、寄养还是散养 + + + +这波 Claw 热潮，其实分两派 。 + + + +一派是自己托管的，包括 OpenClaw、ZeroClaw、PicoClaw。适合对数据隐私敏感的人，或者喜欢折腾的人。 + + + +一派是云端托管的，包括 MaxClaw、Kimi Claw、ArkClaw。适合不想维护服务器、不想搞配置的人。 + + + +自己托管的优点是自己掌握数据，缺点是门槛高。OpenClaw 跑起来要 1GB+ 内存，启动有时候要等好几分钟 。ZeroClaw 倒是轻，内存占用不到 5MB，但要用 Rust 折腾 。 + + + +云端托管的优点是零配置，注册就能用。MaxClaw 专业版 199 块钱一个月，Kimi Claw 专业版 Allegretto 200 多块钱一个月。 + + + +两派各有各的道理，但有一点是共通的：都在疯狂消耗 Token。 + + + +据 openrouter 平台数据，2 月 16 日—22 日，OpenClaw token 消耗量 2.05T；2 月 23 日—3 月 1 日，2.26T 。一个重度用户日均 Token 消耗在 3000 万至 1 亿之间 。 + +黄仁勋最近评价 OpenClaw，说它是“我们这个时代最重要的软件发布” 。他认为，智能体执行复杂任务所需的 Token 消耗量激增了约 1000 倍，直接制造了一个“算力真空” 。 + + + +说白了，这玩意儿就是个抽水机 。每一次安装，都在用户设备和云端建立一台 24 小时运转的 Token 消耗器。 + + + +--- + + + +## 五、尾声 + + + +工信部 3 月 8 日发布预警：OpenClaw 开源 AI 智能体部分实例在默认或不当配置情况下存在较高安全风险，极易引发网络攻击、信息泄露等安全问题 。 + + + +这玩意儿权限太高了。要发邮件就得拿邮件权限，要写文件就得拿文件权限。一旦被恶意利用，后果不堪设想 。 + + + +Peter Steinberger 自己也警告过：“如果你都不懂怎么使用命令行，这个软件对你来说太危险了。” + + + +所以现在很多人选择把它部署在专门的设备上。之前 Mac mini 价格水涨船高，电商网站 3000 多的涨到 4000+，连咸鱼上的二手都在升值 。后来云厂商推出应用模板，2 核 4G 5M 服务器包年才 99，大家才找到了更具性价比的方案。 + + + +最后，如果你问我该选哪个 Claw，我的建议是 ： + + + +- 不想折腾服务器 → Kimi Claw 或 MaxClaw + + + +- 技术爱好者想要完整功能 → OpenClaw + + + +- 服务器配置不高想跑多个机器人 → ZeroClaw + + + +- 给 IoT 设备加智能 → PicoClaw + + + +- 企业用户 → OpenClaw/ZeroClaw + MaxClaw/Kimi Claw 混合用 + + + +--- + + + +emmm，其实，上面的文章你都可以认为是图个乐子，只是我想把最近的 timeline 理清楚， + + + +但我更想说的是另一件事。 + + + +从 OpenClaw 到 ArkClaw，从 QClaw 到 AutoClaw，从自己托管到云端托管，从上门安装到上门保洁——这整场狂欢，本质上是一场关于“谁替你承担风险”的博弈。 + + + +你想自己管，就得承受被黑的可能；你想交给别人，就得接受数据被凝视的现实。 + + + +区块链想解决的问题，Claw 又走了一遍回头路。 + + + +私有化 -> 公有化 -> 私有化 -> 公有化。技术兜兜转转，最后还是回到了那个古老的命题：你愿意为安全付出多少自由，又愿意为自由承担多少风险？ + + + +OpenClaw 的意义，不在于它让 AI 能干活了，也不在于它把算力抽水机搬进了你家。而在于它把这个命题，重新摆在了所有人面前。 + + + +至于答案？ + + + +没有标准答案。 + + + +就像有人把钱藏床底下，有人存银行，有人买黄金，有人梭哈比特币——各有各的道理，也各有各的代价。 + + + +唯一能确定的是，**the claw is the law**。无论你怎么选，它都会在那个角落里，24 小时运转，消耗 Token，替你干活，顺便替你承担风险。 + + + +不过，5G 带来了流量平权时代，我相信，国内大规模的电网普设，也会带来 token 平权时代，因为现在 token 还是，**太 贵 了 ！**。 diff --git "a/ai-articles/01-agent-and-coding/\347\246\273\350\260\261\357\274\214GPT-5.6 \347\253\237\347\204\266\345\234\250\345\220\216\345\217\260\346\211\247\350\241\214\344\272\206 rm -rf.md" "b/ai-articles/01-agent-and-coding/\347\246\273\350\260\261\357\274\214GPT-5.6 \347\253\237\347\204\266\345\234\250\345\220\216\345\217\260\346\211\247\350\241\214\344\272\206 rm -rf.md" new file mode 100644 index 0000000..23fed7e --- /dev/null +++ "b/ai-articles/01-agent-and-coding/\347\246\273\350\260\261\357\274\214GPT-5.6 \347\253\237\347\204\266\345\234\250\345\220\216\345\217\260\346\211\247\350\241\214\344\272\206 rm -rf.md" @@ -0,0 +1,157 @@ +# 离谱，GPT-5.6 竟然在后台执行了 rm -rf + +[English](../../en/ai-articles/01-agent-and-coding/gpt-5-6-ran-rm-rf-in-the-background.md) | [中文](./%E7%A6%BB%E8%B0%B1%EF%BC%8CGPT-5.6%20%E7%AB%9F%E7%84%B6%E5%9C%A8%E5%90%8E%E5%8F%B0%E6%89%A7%E8%A1%8C%E4%BA%86%20rm%20-rf.md) + +> 日期：2026-07-16 + +大家好，我是 cxuan。 + +昨天 GPT 5.6 正式公开，某知名社交平台上全是牛批、卧槽、吊打 Fable 5，很多号主也在跟着吹。 + +但我昨天其实就说过：我要给 GPT 5.6 浇盆冷水。我预感它效果没那么好。 + +[都在吹 GPT 5.6，但我可能得泼点冷水了。](https://mp.weixin.qq.com/s/sylMeZQM_DX2_SOsAM_s3g) + +结果发布才一天多，风向就开始变了。 + +--- + +昨天我没收到 Sol 的推送，所以先测了 Terra。 + +发布时官方口径大概是：Terra 能力和 GPT-5.5 差不多，更省 token。我之前也按这个理解它——**Terra 是 5.5 的省流版**。 + +image-20260711122054159 + +然后体验过程里，首当其冲就撞上两个低级问题。。。。。。 + +一个是模型跑完了，界面上几乎看不到任何结果。 + +一个是流式渲染之后，英文夹着中文一起喷出来，读起来像一坨泔水。 + +image-20260711123204082 + +我还分不清，这是 ChatGPT Codex 客户端的问题，还是模型本身的问题。 + +但结论很简单：**体验有些差。** + +--- + +前天 Grok 4.5 刚出来的时候，我写过一篇，说这次 Grok 4.5 效果其实不错。 + +[Cursor 掀桌子了，Grok 4.5 这次要上天了？](https://mp.weixin.qq.com/s/uibtdVGdjCg6z9qELv1zpQ) + +对 GPT 5.6，我又泼了冷水。 + +**结果这两个观点，现在都在应验。** + +一边是 Grok 4.5 被拿去和第一梯队认真比较。 + +一边是 GPT 5.6 的热度，正在从吊打一切变成寥寥无几的在吹。 + +不是说 5.6 完全不能用。是在说：**发布日的情绪，和真正上手后的体感，不是一回事。** + +### OpenAI 把重置玩明白了 + +现在 OpenAI 倒是很清楚一件事情了：额度重置，比再发一篇评测稿更管用。 + +邀请重置，改 bug 重置，奥特曼打个不会赢的赌输了重置，甚至官方毫无理由直接下场送重置。 + +属实把重置玩明白了。 + +但是这招的副作用也很明显：用户会逐渐把重置当成产品体验的一部分，而不是福利。 + +哪天 OpenAI 如果不送重置了之后呢？ + +用户可是没有忠诚度，哪个模型好用哪个，哪个模型省 token 用哪个，哪个模型性价比高用哪个。 + +比如我之前天天吹 GPT 5.5 ，现在不也是在上手用上了 Grok 4.5 么。。。 + +你要是天天靠补额度维稳，那产品本身一定哪里有问题。 + +### A 社也坐不住了 + +GPT 5.6 这波，连一毛不拔的 A 社都跟着重置额度了。 + +Fable 5 本来是 7 月 7 号结束订阅内的促销额度，后来延到 7 月 12 号；5.6 一公开，A 社又把 5 小时和 weekly limit 全量重置了一遍。 + +Tibo 直接在官方帖子下面说：他闻到了一股恐惧的气味。 + +image-20260711133940980 + +这话当然带点阴阳了。 + +不过可以确定的是，A 社确实感觉到了一些压力。否则也不会在 GPT 5.6 刚发布就选择重置额度。 + +Fable 5 的延迟下线也能证明这一点。 + +--- + +我仍然记得当初用 GPT 5.5 时候的惊艳，但这次 GPT-5.6 Sol，吐槽的人不少。 + +175fb822cf58282570f809d8d0b9bf87 + +Simon Willison 写过 GPT-5.6 家族（Luna / Terra / Sol）的梳理，也承认 Sol 很能干，但在他常做的复杂编码任务上，**目前还没觉得它比 Fable 更好**。 + +另外一个更刺眼的点是：官方爱打的 Agents’ Last Exam 上 Sol 很亮眼，但在 SWE-Bench Pro 这种更硬的编码评测上，Fable 5 自报大约 80%，Sol 大约 64.6%。OpenAI 还专门发文质疑 SWE-Bench Pro 有大量坏题——这个动作本身，也说明编码榜单已经开始互撕了。 + +但是，更严重的是 Matt Shumer。 + +他测试 GPT-5.6 Sol 时，最终执行了类似 `rm -rf /Users/mattsdevbox` 的操作，把 Mac 上的文件全删光了。 + +（Matt Shumer 就是写下那篇《有许多大事儿即将发生》的那位） + +image-20260711125211332 + +出了这件事后，我对 GPT-5.6 Sol 的信任直接掉了一截。 + +Theo（t3.gg）也吐槽了一个很工程的问题：把 gpt-5.6-sol 设成 `ultra` 之后，它下面的所有 subagent 也会继承 `ultra`，造成无缘无故的 token 燃烧，而且还无法单独的把 subagent 的 effort 换成 medium。 + +image-20260711131208541 + +因为很多人第一天就会把 effort 拉满，一拉满就疯狂烧 token ，然后回头说 Sol 太贵了。。。 + +这老哥还有一个帖子更直接，说感谢大厂互卷，让 A 社感到恐惧，于是继续延长 Fable 5 的下线节奏。 + +我甚至觉得，Fable 5 未必会在 12 号就按原计划切到纯 credits。 + +现在先立个 flag，看看会不会打脸。 + +image-20260711134359615 + +--- + +我现在真实感觉到现在的测评，其实看一看就行。 + +真正决定你换不换默认模型的，还是这几件事： + +会不会稳定产出结果，会不会乱删文件，会不会无故烧额度，会不会无缘无故降智，会不会有额外的惊喜。 + +我不是说 GPT 5.6 没有实力，OpenAI 在 agent 长程任务、工具调用、多 agent 编排上确实很突出。 + +但发布后的第一波真实反馈里，**稳定性和可控性**，已经压过了再高 10 分的兴奋。 + +这也是为什么我更愿意先看 Grok 4.5 这类够强、够快、够便宜的选手，而不是只盯着发布会里最顶的那一档。 + +按照现在的趋势，顶级模型不会用来单纯的干活，而是会整理需求、做设计、拿方案，具体干活，要交给工程能力强，token 消耗没那么快的模型。 + +--- + +## + +如果你实在想用 GPT 5.6，**先把 effort 调到 medium，别一上来 ultra 拉满。** + +image-20260711134122300 + +这和我之前写过的一篇，以及现在圈里不少人的观点，基本一致：xhigh / ultra 很容易过度思考，还特别废 token，性价比不高。 + +除非你在做又难又大的攻城略地型任务，否则一般任务里，medium 往往更划算。 + +[还在用 Codex 把 xhigh 拉满跑？](https://mp.weixin.qq.com/s/F9BDZm2JhjvpytyQ2yH4oQ) + +--- + +说到底，GPT 5.6 现在最大的问题，是新版 Codex 搭配着 GPT 5.6 还没稳定，bug 比较多，而且大家对 GPT 5.6 的期待值有些过高，导致与实际情况有些差距，所以我感觉这次 OpenAI 还是有些着急了。 + +我现在的态度很简单：Sol 继续观察，Terra 先当省流备胎（其实并不省），Fable 5 额度能蹬上的话还是最佳选择，Grok 4.5 很值得尝试。 + +现在最应该做的事儿就是等着 GPT 6.x 的发布了。 diff --git "a/ai-articles/01-agent-and-coding/\350\257\273\346\207\202 Claude Code \346\236\266\346\236\204\345\210\206\346\236\220\347\263\273\345\210\227\357\274\214\347\254\254\344\270\200\347\257\207\357\274\214\345\274\200\345\247\213\357\274\201.md" "b/ai-articles/01-agent-and-coding/\350\257\273\346\207\202 Claude Code \346\236\266\346\236\204\345\210\206\346\236\220\347\263\273\345\210\227\357\274\214\347\254\254\344\270\200\347\257\207\357\274\214\345\274\200\345\247\213\357\274\201.md" new file mode 100644 index 0000000..4dbfa35 --- /dev/null +++ "b/ai-articles/01-agent-and-coding/\350\257\273\346\207\202 Claude Code \346\236\266\346\236\204\345\210\206\346\236\220\347\263\273\345\210\227\357\274\214\347\254\254\344\270\200\347\257\207\357\274\214\345\274\200\345\247\213\357\274\201.md" @@ -0,0 +1,673 @@ +# 读懂 Claude Code 架构分析系列，第一篇，开始！ + +[English](../../en/ai-articles/01-agent-and-coding/understanding-claude-code-architecture-part-1.md) | [中文](./%E8%AF%BB%E6%87%82%20Claude%20Code%20%E6%9E%B6%E6%9E%84%E5%88%86%E6%9E%90%E7%B3%BB%E5%88%97%EF%BC%8C%E7%AC%AC%E4%B8%80%E7%AF%87%EF%BC%8C%E5%BC%80%E5%A7%8B%EF%BC%81.md) + +> 日期：2026-06-29 + +系列前景提要： + +我偶然间找着了一个 GitHub 项目，这个 GitHub 项目是针对 Claude Code 泄露的源码进行分析。 + +之前我看到过很多 Claude Code 源码分析文章，要么太具体深入代码，要么 AI 写的太多导致节奏感不好。 + +不过这个 repo 给了我很大的灵感和思路，所以我想根据这个 GitHub 写一个完整的系列。 + +所以我的写作风格会严格把控每一张图，尽我最大的努力做大结构严谨，层次感分明，从架构方面让大家对 Claude Code 有更多的理解。 + + + +Claude Code from Source 封面 + +*▲ 图源：Claude Code from Source 首页封面截图* + +这张封面图充满着反讽意味。 + +首先左上角的 NO' REILLY 致敬一个出版社 O'REILLY ，好像在说，没什么是真实的，是一个恶搞。 + +Alejandro Balderas 本人是 Anthropic 的工程师，在技术社区中，他确实深度参与了 Claude Code的开发工作。但是 Alejandro Balderas 却和 AI 合著了这本书，充满着一语双关的味道。 + +封面中间一个螃蟹举着一个 .map 封面，意指 Claude Code 泄露 .map 文件这件事情，而且这个 map ，也确实可以认为是一张 .map 的地图。 + +（纯属我自己胡乱分析的，大家看个乐呵就好） + +--- + +## 正文开始 + +正文开始，大家可以先想一个问题，Claude Code 到底是什么？ + +传统的 CLI 其本质上就是一个函数，就是一条命令，执行一个操作，获得确定性的输出。 + +比如 `grep` ，你执行 grep 的时候不会要同时运行 `sed`，比如 `curl`，你也不会下载完东西以后，再根据下载的内容进行补全。 + +然后 Agentic CLI 出来了。 + +Agentic CLI 会接受人类自然语言的描述，根据自然语言的提示，来决定使用哪些工具。并且按照具体的情况要求顺序的调用这些工具，获得结果，然后进行循环，直到任务完成或用户停止为止。 + +于是传统的 CLI 方式大家都不用了，都改为使用 Agentic CLI 了。 + +![传统 CLI 与 Agentic CLI 执行结构对比](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@565bdd9/claude-code-from-source/ch01/ch01-00-cli-vs-agent-excalidraw-skill.png) + +*▲ 传统 CLI 是线性管道，Agentic CLI 是围绕模型决策形成的反馈闭环。* + +由此我们可以给 Agentic CLI 下一个定义： + +Agentic CLI 不是一串固定的指令，而是围绕着大语言模型运转的一个循环，模型会在运行时自己生成下一步指令。 + +Claude Code 是一个 TypeScript 的单体应用，它将终端变成了一个由 Claude 驱动的完整开发环境。Claude Code 就是 Anthropic 对这个想法进行了生产级实现的产品。 + +这第一节的内容，就是来聊聊抽象出来的 Claude Code **六种心智模型**。 + +## 六个核心抽象 + +Claude Code 是建立在六个核心抽象之上的。 + +image-20260625201931230 + +*▲ 图源：Claude Code from Source 第一章交互图截图* + +这六个抽象层面分别是： + +**Query Loop、Tool System、Tasks、State、Memory、Hooks。** + +分别对应查询循环、工具系统、任务、状态、记忆和钩子。 + +而除此之外的比如几百个工具函数、终端渲染器、Vim 模拟器、成本追踪器这些，它们的本质上都是在服务这六个抽象。 + +下面我分别来跟大家解释一下。 + +### Query Loop：整个系统的核心 + +第一个抽象是 Query Loop。Query Loop 位于 `query.ts`，大概 1700 行代码。这是一个异步生成器，是整个系统的核心。 + +所以，Claude Code 的核心，就是一轮一轮地跑： + +调用模型 -> 接收流式响应 -> 收集工具调用 -> 执行工具 -> 把工具结果追加回上下文 -> 然后继续下一轮。 + +![image-20260626215559019](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260626215559019.png) + +*▲ Query Loop 是 Claude Code 的统一处理循环：不同入口汇入同一个 `query()`，它一边执行任务，一边把结果持续输出给外部。* + +这里需要注意一点的是：Query Loop 不只是 REPL 的内部实现。 + +>REPL 是什么？REPL 是 **Read-Eval-Print Loop** 的缩写。中文可以理解成：**读取、执行、输出、循环**。它是一种交互式的命令环境。 + +普通的 REPL 、SDK 调用、sub-agent 、无头模式 `--print` 这些，其实都在使用 Query Loop 这种方式。 + +不过 Claude Code 没有给这些入口各写一套 Agent 逻辑，而是把它们最后都汇入同一个 `query()` 循环，然后用 `for await` 方法，一段一段地消费大模型通过工具调用输出的事件。 + +如果用伪代码，大概是这样的： + +```ts +for await (const event of query(input)) { + render(event) +} +``` + +如果用生活中的例子来解释：大概是快递分拣包裹中，有一个集装箱，机械臂可以一轮一轮实时把包裹进行分拣，分拣完成后再装箱，最后进行运输。 + +Agent 在调用 query 方法对用户的输入进行处理，处理完成后会产生原始的 event 事件，这些 event 事件是大模型产生的原始事件，这些事件无法直接返回给用户，需要 Agent 对其进行一层渲染、包装一层 Message 事件后，再返回给用户。 + +我用 `claude -p` 实际跑了一下，来看看具体的 Message 事件长啥样，这样会帮助你更好理解（数据已脱敏） + +```json +{"type":"system","subtype":"init","cwd":"","session_id":"","tools":["Read","Edit","Bash","..."],"model":""} +{"type":"system","subtype":"status","status":"requesting"} +{"type":"stream_event","event":{"type":"message_start"}} +{"type":"stream_event","event":{"type":"content_block_delta","delta":{"type":"text_delta","text":"你好！"}}} +{"type":"assistant","message":{"role":"assistant","content":[{"type":"text","text":"你好！"}]}} +{"type":"stream_event","event":{"type":"message_delta","delta":{"stop_reason":"end_turn"}}} +{"type":"result","subtype":"success","result":"你好！","stop_reason":"end_turn"} +``` + +开头的 system/init 表示 Claude Code 开始初始化会话； + +system/status requesting 表示 Claude Code 开始请求模型； + +stream_event/message_start 表示模型开始返回流式响应； + +stream_event/content_block_delta 表示模型在持续输出； + +assistant 是 SDK 整理出来的 assistant Message ； + +stream_event/message_delta 是消息级别的更新； + +最后的 result/success 表示整个 query() 执行完成。 + +--- + +整个循环是一个 async generator，也就是异步生成的。 + +啥意思呢？ + +简单来说，它不是一次性跑完再返回结果，而是一边运行，一边不断产出新的 event 事件。 + +（这些事件可以是模型输出的一段文本，可以是一次工具调用，可以是工具执行结果，也可以是最后的停止事件。） + +这种设计会存在几类好处： + +第一，输出节奏可控。 +Agent 执行时会不断产生东西：模型的文本、工具的调用、工具执行的结果、状态的变化。如果用普通事件回调，循环里面会不管循环外面处理得快不快，一直会产生新的 event 事件。 + +如果用户终端处理不过来，很可能会导致消息积压。 + +第二，用户需要中断时，能够及时响应。 + +如果用户按了 `Ctrl+C`，或者外部调用方取消了请求。 + +因为这时候模型调用可能还没结束，工具可能还在跑，子任务也可能还在继续执行。 + +这时是一堆 callback 到处飞的话，很容易出现一个问题：表面上停了，实际上后台还在继续执行。 + +最后到底是用户取消、工具调用失败，还是系统异常，就说不清楚了。 + +async generator 的好处是，它有一个明确的停止信号可以做判断。 + +用户希望取消执行，Agent 就可以沿着这条执行链路进行收尾：停止继续产出事件，通知正在运行的任务中断，并把最后的停止原因标记为用户取消。 + +第三，也是最重要的，它会说清楚停止的原因是什么。 + +任务停止后，在最后输出的 result Message 里会带着 `stop_reason`。 + +它可以直接根据这个结果决定下一步怎么处理。 + +![Agent 停止原因示意图](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@7d97afd/claude-code-from-source/ch01/ch01-02-stop-reason-explained.png) + +*▲ Claude Code 停止原因* + +它能够清晰的表明到底因为啥而停止，而不是告诉用户，任务停了。 + +### 2. Tool System：工具系统 + +第二个抽象是工具系统，源码在`Tool.ts`, `tools.ts`, `services/tools/` 中。 + +工具就是 Agent 在电脑世界里到底能干哪些活。 + +比如我们日常使用的读文件、跑 shell、编辑代码、搜索网页，都是在调用工具。 + +这句话虽然看起来很简单，这其实里面是一套完整的工具系统，复杂度很高。 + +Claude Code 中的每个工具都实现了丰富的接口，这些接口都涵盖了身份、模式、执行、权限和渲染等方面。 + +这里需要先给各位小伙伴介绍两个概念：一个是**工具执行器**，一个是**流式调度器**。 + +工具执行器比较好理解，它就是负责执行工具。比如 Read、Write、Bash、Grep 等。 + +但工具执行器会在执行的时候，将工具调用分为串行执行和并发执行。 + +比如读文件通常可以并行执行，但写文件、跑会修改状态的命令，就不能随意并行执行。 + +而**流式调度器** 更像工具执行器里面的一种优化机制，或者一种执行策略。 + +它关心的是：能不能在模型还没完整输出完之前，就提前启动某些工具？ + +比如模型刚刚输出一个 `Read` 调用，如果 `Read` 是并发安全的，流式调度器就可以马上启动它，Agent 就可以先去读文件。 + +此时模型还在继续执行，但读文件已经结束了。 + +Tool System 流式调度动图 + +*▲ 工具系统可以边接收模型输出，边判断哪些工具可以直接使用。* + +Claude Code 把工具执行和模型流式输出揉在了一起。 + +### 3. Tasks：后台任务和 sub-agent + +第三个抽象是 Tasks。源码在 `Task.ts`, `tasks/` 文件中。 + +Task 主要是后台的执行单元，它用来承载 sub-agent 。 + +每个 sub-agent 都有一个状态机：包含下面这几种状态 。 + +`pending -> running -> completed | failed | killed` + +也就是等待、运行、完成、失败、被杀掉。 + +![sub-agent Query Loop 示意图](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@128dfa7/claude-code-from-source/ch01/ch01-04-tasks-sub-agent-query-loop-clean.png) + +*▲ sub-agent 是由 AgentTool 启动的一条新 Query Loop。它有自己的消息历史、工具集合和权限模式。* + +重点在于 `AgentTool`。 + +当 Claude Code fork 出来一个 sub-agent 的时候，fork 出 sub-agent 的被称为父 Agent，sub-agent 和父 Agent 走的是同一套 query loop ，只不过 sub-agent 是调用 Query 方法来启动的新的 query loop 。 + +这个新的 query loop 有自己的上下文、自己的工具集合、自己的权限模式，所以它也是一个小的 Agent。 + +这种 fork 的方式就给 Claude Code 带来了递归能力： + +**一个 Agent 可以代理给另一个 Agent，另一个 Agent 还可以继续向下进行代理。** + +但这里也存在一定的危险性，因为一旦 sub-agent 能自己做决定、自己跑命令、自己改文件，系统就有可能失控。 + +所以后面权限系统里有一个很重要的 `bubble` 模式，这个后面会讲到。 + +意思是：sub-agent 遇到危险动作，不能自己批准，需要进行上报，让父 Agent 或用户来决定。 + +这是多 Agent 系统里很重要的红线。 + +### 4. State：两层状态 + +第四个抽象是状态。 + +Claude Code 有两层状态。 + +第一层是一个可变单例 `STATE`状态 + +它保存的是**会话级**基础状态，比如当前工作目录、模型配置、成本追踪、session ID，一共大概 80 个字段。 + +会话级大家理解是什么意思吧。当你在 Claude Code 每开一个窗口，其实都是 session 级。 + +session 会记录下面这些状态（一部分）： + +```markdown +当前在哪个目录运行 +现在用哪个模型 +这次会话的 session id 是什么 +已经花了多少钱 +已经用了多少 token +当前权限模式是什么 +``` + +当 Claude Code 启动时，会把这些信息放进 `STATE`： + +```ts +STATE.cwd = 当前工作目录 +STATE.sessionId = 本次会话 ID +STATE.model = 当前模型 +STATE.permissionMode = 当前权限模式 +``` + +后面如果要改，就直接改这个对象本身就可以。 + +![STATE 会话级状态示意图](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@13856fc/claude-code-from-source/ch01/ch01-05-state-session-registry.png) + +*▲ 第一层 `STATE` 更像一张会话级运行登记表：启动时初始化，运行中直接修改，系统模块按需读取。* + + +第二层是 UI 的**界面状态**，里面会有这些设定。 + +```mar +新的消息来了 +输入模式变了 +正在等待用户批准工具调用 +进度条更新了 +模型正在输出 +``` + +这些状态改变之后，UI 就要跟着改。 + +React 这门语言里面，有一个叫做 `Zustand` 的东西，这是一个 React 的状态管理机制，这个机制来驱动着这些界面状态的改变。 + +伪代码如下 + +```ts +const useStore = create((set, get) => ({ + messages: [], + inputMode: "normal", + + addMessage: (msg) => + set((state) => ({ + messages: [...state.messages, msg], + })), + + setInputMode: (mode) => + set({ inputMode: mode }), +})) +``` + +很简单，就一个 get、 set 方法，通过简单的 set/get 更新和读取，UI 可以监听这些变化。 + +![响应式界面状态示意图](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@6d64e2b/claude-code-from-source/ch01/ch01-06-state-reactive-ui-store.png) + +*▲ 通过 `set()` 写入，通过 `get()` 读取，状态变化后通知 UI 重新渲染。* + + +界面状态这里是用了**响应式（reactive）**的设计，原因也比较简单，因为 UI 状态的改变是实时的。 + +但不是所有状态都应该 reactive。 + +像是上面的 State 状态的改变，就不是响应式；而 UI 状态这种需要实时改变的，就需要响应式设计。 + +### 5. Memory：跨会话的上下文 + +第五个抽象是 Memory，在 `memdir/` 路径下。 + +memory 就是 Agent 在 session 间的持久上下文。 + +原文说 Claude Code 的记忆有三层，Claude 官方也说了是有三层。 + +但我认为应该是有四层，最后一层其实算团队级。 + +* 用户级：`~/.claude/CLAUDE.md`，对于 Claude 全局生效。 +* 项目级：仓库里的 `CLAUDE.md`，对于项目全局生效。 +* 目录/模块级：业务模块路径中的 `CLAUDE.md`，对于模块全局生效（官方把这一层归到了项目集里面） +* 团队级：通过软连接实现，普通开发者一般不会直接维护。 + +![Memory 跨会话上下文示意图](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@7e2c521/claude-code-from-source/ch01/ch01-07-memory-cross-session-context.png) + +*▲ Memory 把长期有用的信息写成 Markdown 文件，会话开始时筛选相关内容，再交给 Query Loop 使用。* + +每次会话开始时，系统会扫描这些 memory 文件，解析 frontmatter，再让 LLM 判断哪些记忆和当前对话相关，再进入 Query Loop 循环中。 + +项目约定、架构决策、调试历史、个人偏好这些，都适合沉淀成为 Memory，并且 md 格式是一份能打开、能编辑、方便版本管理的文件。 + +我现在有一种想法，或许 Agent 记忆最好的形态就是可维护的 Memory.md 。 + +### 6. Hooks：生命周期拦截器 + +第六个抽象是 Hooks，在 `hooks/`, `utils/hooks/` 路径下。 + +Hooks 是用户自定义的 Claude Code 全生命周期的拦截器。 + +原文说，Claude Code 的 hooks 会在 4 类执行类型、27 个不同事件上触发。 + +这 4 类包括 **shell 命令、一次性 LLM prompt、多轮 Agent 对话、HTTP webhook。** + +如果你熟悉 Java Spring 框架的话，这个 Hooks ，就很像 Spring 中 AOP 的设计理念。 + +但是还不完全一样，Spring AOP 拦的是 Java 方法调用，而 Claude Code Hooks 拦的是 Claude Code 预定义的生命周期事件，比如工具调用前后、prompt 提交、会话结束等。 + +![image-20260627144932971](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260627144932971.png) + +*▲ Hooks 和 Spring AOP 异同情况。* + +Hooks 可以做很多事：阻止工具执行，修改输入，注入额外上下文，甚至直接阻塞整个 query loop。 + +更有意思的是，权限系统本身也部分通过 hooks 实现。 + +比如 `PreToolUse` hook 可以在交互式权限提示出现之前，就拒绝某个工具的调用。 + +## 一次 Claude Code 的完整请求 + +下面是一次 Claude Code 的完整请求，从用户发送消息请求开始。 + +用户输入：“给登录函数加错误处理”，然后按下回车。 + +![Claude Code Golden Path 动态演示](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@e05657e/claude-code-from-source/ch01/ch01-09-golden-path-flow.gif) + +*▲ Golden Path 动态演示：一次请求从 REPL 进入 Query Loop，经过模型流式响应、工具执行，再回到终端输出。* + +完整的静态效果如下。 + +![Claude Code Golden Path 静态完整路径](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@e05657e/claude-code-from-source/ch01/ch01-10-golden-path-static-full-path.png) + +*▲ Golden Path 静态完整路径，方便对照* + +这条路径大概是这样： + +用户在 Claude Code 终端输入任务。 + +REPL 把消息交给 Query Loop。 + +Query Loop 会调用模型 API。 + +模型流式返回内容和工具调用。 + +如果模型要读文件、改文件、跑命令，就交给流式调度器。 + +工具系统再执行具体的动作。 + +工具执行的结果会沉淀成为 session 上下文。 + +Query Loop 带着新上下文再次调用模型。 + +直到模型不再请求工具，或者外部条件让它停下。 + +整个执行过程中有三点需要注意。 + +第一，query loop 是 generator，不是 callback chain。callback chain 也是回调链，一个函数里面有无数个回调函数。 + +callback chain 的伪代码如下： + +```ts +runAgent(input, { + onText(text) {}, + onToolCall(tool) {}, + onToolResult(result) {}, + onDone(reason) {}, + onError(error) {}, +}) +``` + +callback chain 最大的弊端，是最外层的 runAgent 方法，没有里面回调函数的执行权。 + +啥意思呢，就是说里面的函数如何执行，外层的 runAgent 无法控制，他只起到被通知执行完成的作用。 + +而 query loop 不一样，他是用 `for await` 从里面拉消息的。 + +```ts +for await (const msg of query(input)) { + render(msg) +} +``` + +外面每次循环取一条消息，当外面处理完这一条消息后，才继续处理下一条。 + +>callback chain 是“里面主动推”。 +> +>generator 是“外面主动拉”。 +> +>也就是说 callback chain 和 generator 最大的区别是控制权的归属。 + +在 query loop 结构中，这意味着终端 UI 的消费速度会影响生成速度。 + +这块设计它有点像 TCP 滑动窗口背后的思想：接收方处理不过来，发送方就不能无限制发送请求。 + +第二，Claude Code 不一定等模型整句话说完，才开始执行工具。 + +一般的做法是这样的： + +模型完整输出一段回复，Agent 看完回复，发现里面有工具调用，然后开始执行工具，工具执行完成后，再把结果交回模型。 + +![普通串行工具执行流程](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@2ea13e5/claude-code-from-source/ch01/ch01-11-streaming-serial-tool-flow.png) + +*▲ 普通串行方式：模型先完整输出，系统再发现工具调用，然后才开始执行工具。* + +Claude Code 不是这样做的，Claude Code 有个 StreamingToolExecutor ，它不会傻等模型整段回复结束后再调用相应的工具。 + +只要它看到一个工具是并发安全的，就可以先执行，比如 Read 和 Grep 。 + +当模型还在继续生成的时候，文件可能已经读完了。原文把这叫 `speculative execution`，择机执行。 + +不过，这种方式也有代价，代价是有可能会重跑，白白消耗 token 。 + +因为如果后面模型输出改变了前面的结果，那么前面的结果可能要丢掉，虽然这种情况出现的次数比较少，但也不能忽视。 + +**这是 Claude Code 在用可能浪费的算力，来换取整体延迟性的降低。** + +第三，整个循环是可重入的。 + +当模型在调用工具后，执行结果会被添加到当前窗口的上下文中，然后循环依据上下文的消息，调用工具继续执行，结果再写回上下文中。比如下面这个例子 + +```text +用户提问 +-> 模型判断：我要读文件 +-> 工具读文件 +-> 读到的内容放回上下文 +-> 模型再看这些内容 +-> 模型判断：我要改文件 +-> 工具改文件 +-> 修改结果再放回上下文 +-> 模型再看结果 +-> 模型判断：可以结束 +-> 最终回复用户 +``` + +![image-20260629071056159](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260629071056159.png) + +*▲ Agent 运行时循环：模型看上下文决定下一步，工具结果再写回上下文。* + +## 权限系统 + +Claude Code 能在你机器上执行任何 shell 命令。 + +它能改文件，能开子进程，能发网络请求，能改 git 历史。 + +所以如果没有权限系统对 Agent 进行控制，这就是灾难。 + +我经常看到非常多的国内小伙伴直接 Bypass permissions 开着跑，而美其名曰你都用上 AI 了，还能怕它搞出事儿来么。 + +但据我所知，国外很多开发者是不会轻易开这个权限的，我看过 OpenAI 发布会上的开发者用的也只是 acceptEdits。 + +Claude Code 总共有七种权限模式，从最放开到最保守大概是这样： + +（需要注意的是，这是源码层面的权限模式，而不是你在 Claude Code 中可以切换的模式） + +| 模式 | 含义 | +| ------------------- | ------------------------------------------- | +| `bypassPermissions` | 全部放行，不做检查，主要是内部或测试用 | +| `dontAsk` | 都允许，但仍然会记录日志。 | +| `auto` | 用一个轻量 LLM 分类器判断该 allow 还是 deny | +| `acceptEdits` | 文件编辑自动批准，其他操作仍问 | +| `default` | 标准交互模式，每个关键动作让用户确认 | +| `plan` | 只读模式，所有写操作都禁止 | +| `bubble` | sub-agent 不自己决定，把权限上抛给父级 | + +当工具调用需要权限时，其解决过程遵循严格的流程： + +![Claude Code 权限解析动态演示](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@635720a/claude-code-from-source/ch01/ch01-13-permission-resolution-flow.gif) + +*▲ Claude Code 权限解析动态演示：Hook、工具自检、权限模式会依次参与决策。* + +bypass/dontAsk/acceptEdits/plan 这四个策略是写死的静态策略。default 是人来做每个确认。bubble 是每次都往上抛，由父 Agent 做决定。 + +这块需要说一下的权限模式是 `auto`。 + +**auto 模式在判断前都会额外调用一次轻量 LLM，让这个 LLM 来判断是否符合用户原始意图。** + +所以 auto 本质上是在全手动确认和权限完全放开之间，加了一层自动审批。 + +如果用户让它改 bug ，读文件、跑测试、改相关文件可能合理。 + +但如果它突然要删目录了、改 SSH 配置了，就应该停下来等用户确认。 + +sub-agent 默认走 `bubble` 模式也很关键。 + +bubble 就是冒泡，想象一下水里的气泡是否会浮到水面上，bubble 模式是一样的，而水面就是父 Agent。 + +因为 sub-agent 不能自己批准自己的危险动作。它要向上层 Agent 汇报，上层 Agent 根据自身的权限判断是否向用户申请。 + +## 多 Provider 架构 + +Claude Code 是一种 `multi-provider`，也就是多 Provider 的架构。 + +Claude Code 可以通过四种不同基础设施路径访问 Claude。 + +直接 API、AWS Bedrock、Google Vertex AI、Foundry。 + +但这些差异对系统其他部分是透明的，系统的其他部分不会知道，也不关心多 Provider 。![Claude Code Multi-Provider 架构](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@45e45a2/claude-code-from-source/ch01/ch01-04-multi-provider-architecture.png) + +*▲ 多 Provider 的架构模式* + +Anthropic SDK 给不同云厂商都做了适配 wrapper，这些 wrapper 对外暴露同一套接口。 + +`getAnthropicClient()` 是一个工厂函数，这个工厂函数会读取环境变量和配置，决定当前该用哪个 provider，然后构建对应的 client 。 + +构建完成后，`callModel()` 和其他调用方都只会把它当成一个通用 Anthropic client。 + +这里很像工厂模式 + 适配器模式。 + +工厂模式解决的是启动时到底创建哪个 Provider。 + +适配器模式解决的是 Client 创建出来以后，外层用同一套接口调用它。 + +除此之外，callModel() 在选择调用方的时候，其实还用了策略模式。 + +不过，Query Loop 不关心你走的是 Direct API 还是 Bedrock，Provider 选择在启动时完成，直接将结果存进 `STATE`。 + +后面的 Agent Loop、工具系统、权限系统，都不会管 provider 是啥，职责分离。 + +## 构建系统 + +这一节讲构建系统。 + +Claude Code 既是 Anthropic 内部工具，也是公开的 npm 包。 + +这俩使用同一套代码库，然后通过编译时特性标志来控制包含哪些内容。 + +```ts +const module = feature("SOME_FLAG") + ? require("./some/internal/module") + : null +``` + +这里的 `feature()` 来自 `bun:bundle`，也就是 Bun 的内置打包 API。 + +在构建时，每个 feature flag 会被解析成布尔字面量。 + +如果 flag 是 false，打包器会把对应 `require()` 整段删掉。 + +移除之后，模块不会加载，不会进 bundle，也不会发布。 + +也就是说 Claude Code 不是简单靠运行时判断来隐藏内部功能，它是在构建期就把某些路径裁掉。 + +但讽刺的地方就在这儿了。 + +早期 npm 包发布出来的 source map 里带了 `sourcesContent`。 + +这个字段包含原始 TypeScript 源码。 + +也就是说，feature flags 确实把运行时代码裁掉了，但是 source map 还保留着源码内容。 + +这直接导致了 Claude Code 源码被扒出来。 + +## 这些组件怎么连起来 + +所以回到刚开始看到的六个组件，这六个组件具有密切的关联关系。 + +![Claude Code 组件连接图](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@45e45a2/claude-code-from-source/ch01/ch01-05-how-the-pieces-connect.png) + +Memory 会作为系统提示词的一部分喂给 Query Loop。 + +Query Loop 驱动工具执行。 + +工具结果再作为消息回到 Query Loop。 + +Tasks 是递归的 Query Loop，只是有隔离的上下文。 + +Hooks 会在定义好的位置拦截 Query Loop。 + +State 被所有模块读写，同时响应设计会实时订阅 UI 状态。 + +**Query Loop 和 Tool System 之间的循环依赖，是这个系统最核心的特征。** + +直到模型不再生成工具调用，或者 token 预算、最大轮次到了、用户取消之类的外部约束把它终止为止。 + +这就是 Agent 的本质。 + +所以现在可以回答正文开头哪句 Claude Code 到底是什么的问题了。 + +它是一个跑在终端里的 Agent runtime。 + +模型只是大脑。 + +工具是手脚。 + +权限是刹车系统 + +状态是神经系统。 + +Memory 是长期经验。 + +Hooks 是工程纪律。 + +Query Loop 才是心跳。 + +所以。。。你觉得它是什么？ + +后续章节我会沿着一次 Claude Code 的完整请求来展开，为大家介绍。 + +所以第一章算是提纲挈领性质的内容。 + +下一篇我会启动第二章：启动流程。 + +--- + +参考资料： + +- Claude Code from Source, Chapter 1: The Architecture of an AI Agent + https://claude-code-from-source.com/ch01-architecture/ +- Claude Code from Source 首页 + https://claude-code-from-source.com/ +- Anthropic Claude Code Docs: Overview + https://docs.anthropic.com/en/docs/claude-code/overview diff --git "a/ai-articles/01-agent-and-coding/\350\257\273\346\207\202 Claude Code \346\236\266\346\236\204\345\210\206\346\236\220\347\263\273\345\210\227\357\274\214\347\254\254\344\272\214\347\257\207\357\274\232Claude Code \346\230\257\346\200\216\346\240\267\345\220\257\345\212\250\347\232\204\357\274\237.md" "b/ai-articles/01-agent-and-coding/\350\257\273\346\207\202 Claude Code \346\236\266\346\236\204\345\210\206\346\236\220\347\263\273\345\210\227\357\274\214\347\254\254\344\272\214\347\257\207\357\274\232Claude Code \346\230\257\346\200\216\346\240\267\345\220\257\345\212\250\347\232\204\357\274\237.md" new file mode 100644 index 0000000..4a42b80 --- /dev/null +++ "b/ai-articles/01-agent-and-coding/\350\257\273\346\207\202 Claude Code \346\236\266\346\236\204\345\210\206\346\236\220\347\263\273\345\210\227\357\274\214\347\254\254\344\272\214\347\257\207\357\274\232Claude Code \346\230\257\346\200\216\346\240\267\345\220\257\345\212\250\347\232\204\357\274\237.md" @@ -0,0 +1,552 @@ +# 读懂 Claude Code 架构分析系列，第二篇：Claude Code 是怎样启动的？ + +[English](../../en/ai-articles/01-agent-and-coding/understanding-claude-code-architecture-part-2-fast-startup.md) | [中文](./%E8%AF%BB%E6%87%82%20Claude%20Code%20%E6%9E%B6%E6%9E%84%E5%88%86%E6%9E%90%E7%B3%BB%E5%88%97%EF%BC%8C%E7%AC%AC%E4%BA%8C%E7%AF%87%EF%BC%9AClaude%20Code%20%E6%98%AF%E6%80%8E%E6%A0%B7%E5%90%AF%E5%8A%A8%E7%9A%84%EF%BC%9F.md) + +> 日期：2026-07-07 + +我正在连载 Claude Code 系列体系文章，这是整个系列的第二篇。如果你觉得这个系列不错的话，欢迎追更，完全免费。 + +Claude Code 是一个跑在终端里的 Agent runtime。 + +它里面有 Query Loop，有 Tool System、Tasks、State、 Memory、Hooks。 + +这些东西听起来已经够复杂了。 + +那么问题来了。 + +Claude Code 里面塞了这么多东西，为什么用户在终端里敲下 `claude` 之后，它还能很快的把用户的输入光标显示出来？ + +Claude Code 在启动 CLI 的过程中，都做了哪些事儿？ + +这篇文章讲的就是这件事情，也就是 **Claude Code 的快速启动**。 + +> 原文给 Claude Code 设定的启动预算，大概是 **300ms**。 +> +> 这里的 300ms 可以看成 Claude Code 给 CLI 启动画的一条红线，而不是放在哪都成立的铁律。 +> +> 只要启动时间控制在这个量级，用户通常会觉得工具是秒开的。 +> +> 如果超过这个临界值，CLI 就会开始变得迟钝，用户从体感上来说就会觉得这是个啥玩意，卡的要死。 + +毕竟 CLI 工具和 web 端应用不一样。 + +web 端可以做懒加载，可以做 UI 降级，可以做延迟渲染，接口可以分批请求，非核心功能可以等用户使用时再加载。 + +更甚至加载不过来的话，用户可能被弹出来个 loading。。。。。。 + +但如果终端工具响应慢，体感会非常明显，因为 CLI 的加载过程，用户可是 Online 在线等啊，这事儿挺急的。 + +比如你只是想查个版本号，结果它在那里转半天，这能行吗？ + +所以 CLI 慢一点都忍不了，慢就会被人吐槽，慢慢丢失用户，后面没人用了。 + +所以 Claude Code 启动时既要验证环境、建立安全边界、准备通信层和终端界面，还要把整个过程压在 300ms 左右。 + +所以这一章在聊的就是这个话题。 + +## 启动流程 + +很多项目的启动流程，最后都会成为一个巨大的 `init()`。 + +读配置 => 读环境变量 => 初始化日志 => 加载插件 => 注册命令 => 连接网络 => 渲染 UI。 + +所有东西全揉在一起，你不知道哪些步骤必须现在做，哪些步骤可以晚点做，哪些步骤根本不用做。 + +Claude Code 不是这么做的，它没有把所有的启动步骤都直接塞一块儿。 + +启动请求分流对比图 + +而是把启动流程拆在五个组件里： + +`cli.tsx -> main.tsx -> init.ts -> setup.ts -> replLauncher.ts` + +这五个步骤就像是一条 pipeline 流水线 。 + +Claude Code Bootstrap Pipeline 动图 + +*▲ pipeline 的每一层，都是一个逐层收窄的过程。* + +大家可以先大致记下这张图。 + +在每一层中，每个组件都只执行最小的必要工作，完成后将控制权移交给下一层。 + +这五层其实分别在回答五个问题： + +`cli.tsx`：这次要不要完整启动？ + +`main.tsx`：有没有执行速度比较慢的操作可以异步执行？ + +`init.ts`：当前环境能不能相信，配置是什么？ + +`setup.ts`：Claude Code 有哪些组件可以使用？ + +`replLauncher.ts`：最后从哪个入口进入 Query Loop 循环？ + +后面每一步骤我会跟大家细嗦，你先记住这个点： + +**启动流程的第一步，是先判断有没有必要完整启动。** + +## Phase 0：快速路径调度（cli.tsx） + +Claude Code 进程最先进入的文件是 `cli.tsx`。 + +此时 `cli.tsx` 只有一个核心任务（注意我说的是此时）。 + +**判断这次请求要不要进入完整 Bootstrap。** + +这个设计其实很像操作系统启动里的 bootloader。 + +我这里先简单跟大家拓展一下操作系统中传统 BIOS + MBR 的启动流程。 + +机器刚通电时，CPU 并不知道操作系统在哪里。 + +它只知道一件事：从一个固定地址开始执行第一条指令。 + +在现代 x86 体系里，这个入口通常可以理解为 `0xFFFFFFF0`，也就是所谓的 Reset Vector。 + +这个地址并不存放操作系统，它会映射到主板上的 BIOS 固件 ROM。 + +这里通常不会放很多代码，一般只是放一条 `jump` 跳转指令，把 CPU 带到真正的 BIOS 初始化代码里。 + +BIOS 启动后，会初始化基础硬件，然后根据启动顺序去找启动盘。 + +在传统 BIOS + MBR 启动模式下，BIOS 会读取启动盘的第一个扇区，也就是 MBR，并把它加载到内存中的 `0x7C00` 位置。 + +接着 BIOS 跳到 `0x7C00` 执行。 + +这里放的是最早期的 bootloader 代码。 + +bootloader 再继续加载后续引导程序，比如 GRUB，最后由 GRUB 加载 Linux kernel。 + +所以完整一点就是： + +```text +CPU 从 0xFFFFFFF0 开始执行 + -> 进入 BIOS + -> BIOS 初始化基础硬件 + -> BIOS 找启动盘 + -> BIOS 把 MBR 加载到 0x7C00 + -> 跳到 0x7C00 执行 bootloader + -> bootloader / GRUB 加载 Linux kernel +``` + +image-20260702215811159 + +*▲ 两者共同的地方。* + +为什么要扯这个？ + +因为 `cli.tsx` 在 Claude Code 里的角色，就很像这个 bootloader。`cli.tsx` 第一件事不是加载完整 Claude Code ，而是先判断要不要启动完整的 Agent 。 + +它会先看有没有命令行参数，也就是 `argv`。 + +比如： + +```bash +claude --version +claude --help +claude mcp list +``` + +这些命令其实不需要启动完整的 Claude Code。 + +你就只想看看版本号、获取帮助、列出 MCP Server 等，这时候根本不需要加载 React，初始化 telemetry，读取 keychain，加载工具系统。 + +所以 `cli.tsx` 会先判断这是否是一个可以直接执行的指令，如果是，就直接处理并退出，这条路径就叫 `fast path`。 + +大概是这个意思： + +```ts +if (args.length === 1 && args[0] === "--version") { + const { printVersion } = await import("./commands/version.js") + await printVersion() + process.exit(0) +} +``` + +注意这里用了动态 `import()`。 + +它不是一上来把所有命令模块都加载进来，它只加载当前命令需要的那个模块。 + +如果用户只是查版本号，那就只 Import 版本号相关代码，执行完成然后退出，不用管后面的 `main.tsx`、`init.ts`、`setup.ts`。 + +> 原文说这里大概有十几个 fast path，覆盖 version、help、配置、MCP 管理、更新检查等场景。 +> +> 具体细节并不重要，重要的是这个模式，动态 import ，执行，退出。 + +## Phase 1：异步执行慢 I/O（main.tsx） + +如果 fast path 没命中，`cli.tsx` 就会进入完整启动流程。 + +完整启动的第一步，就是加载 `main.tsx`。 + +这是第二个很重要的执行步骤。 + +`main.tsx` 在模块加载阶段，下面这段代码会在执行任何函数前触发，这是整个 bootstrap 流程中最关键的性能优化技术。 + +```ts +const mdmPromise = startMDMSubprocess() +const keychainPromise = readKeychainCredentials() +``` + +这两块代码是啥意思呢？ + +MDM 是 `Mobile Device Management`，移动设备管理。公司给员工发 Mac，一般会用 MDM 管理设备策略，相当于就是企业给员工个人电脑设置的一系列配置。 + +Claude Code 如果运行在企业设备上，就不能当做个人电脑处理。启动时需要检查 MDM，看看有没有企业级限制。 + +而 Keychain 是 macOS 的系统钥匙串。它用来安全保存密码、token、证书、登录凭据。 + +这两个都是 I/O 型操作，I/O 操作的一个痛点就是慢。 + +I/O 操作不能等着 Claude Code 加载完对应的 ts 模块后再执行，而是先让这两个操作异步执行，然后 Claude Code 并行走接下来的模块加载。 + +main.tsx 模块加载与 I/O 重叠动图 + +*▲ 模块加载和异步 I/O 同时执行。* + +Claude Code 在用同步加载模块的时间来覆盖异步等待。 + +## Phase 2：解析配置与建立信任边界（init.ts） + +`main.tsx` 之后，会进入 `init.ts`。 + +它会解析命令行参数，读取全局配置和项目配置，并在用户确认信任后应用完整的环境配置。 + +> 这里原文提到一个细节：`init()` 是 memoized 的。 +> +> memoized 在这里可以理解为：第一次调用时执行初始化，并把对应的 Promise 或结果缓存下来。后面再调用 `init()`，拿到的还是同一份执行结果，不会重新执行一遍。 + +伪代码如下 + +```ts +let initPromise + +function init() { + if (!initPromise) { + initPromise = reallyInit() + } + + return initPromise +} +``` + +为什么要这么设计？ + +因为 Claude Code 会有多个调用入口，REPL、claude -p 、外部 SDK 调用也会用到。 + +如果每个入口都进行初始化的话，就很容易出现重复初始化。 + +比如配置重复读取、初始化状态重复写入。 + +Claude Code 的 memoized 的 `init()` 把这类问题规避了。 + +`init.ts` 里面有个很重要的东西，是`trust boundary`，可以理解为是信任边界。 + +这里的 trust boundary 关注的是： + +**当前目录、shell 环境、项目配置，是否可以信任，以及能不能被后续启动流程继续使用。** + +Claude Code Trust Boundary + +因为 Claude Code 启动的子进程，会继承当前 shell 里的环境变量。 + +`.bashrc`、`.zshrc`，或者被用户执行、`source` 过的项目脚本，都可以修改这些环境变量。 + +> 注意，项目脚本只是放在目录里不会自动生效，必须先被执行或加载进当前 shell。 + +举个最直观的例子。 + +假设某个陌生项目里放了一个假的 `bin/git`，项目的初始化脚本又执行了下面这句： + +```bash +export PATH="$PWD/bin:$PATH" +``` + +`PATH` 决定系统去哪些目录里寻找命令，而且排在前面的目录优先级更高。 + +这条配置会把项目自己的 `bin` 放到最前面。后面 Claude Code 执行 `git status` 时，系统找到的可能不是电脑里真正的 Git，而是项目准备的那个假 `git`。 + +`NODE_OPTIONS` 也有类似风险。它可以要求 Node.js 子进程在启动时额外加载一段 JavaScript。 + +`LD_PRELOAD` 则主要出现在 Linux 上，它可以让动态链接器在程序启动前先加载指定的共享库。 + +在用户确认信任当前目录之前，Claude Code 只读取不依赖项目环境的安全信息。 + +用户确认信任当前目录以后，它才会读取 `PATH`、`LD_PRELOAD`、`NODE_OPTIONS` 这类可能影响进程行为的环境变量。 + +等环境和配置确认完成，后面的 `setup.ts` 才继续注册命令、Agent、Hooks、插件等能力。 + +### Commander 的 preAction Hook + +> 原文在 `init.ts` 里还提到了 Commander 的 `preAction` hook。 +> +> 我们上一节说到，hook 就是用户自定义的 Claude Code 全生命周期的拦截器。 +> +> 而`preAction` 是 Commander 提供的命令执行钩子。 +> +> 它和 Claude Code 里用户配置的生命周期 Hooks 属于两套机制，只是名字里都有 Hook。 + +Commander 是 Node 生态里一个常见的 CLI 参数解析库。 + +Commander 会解析 flags（选项）、subcommands（子命令）、positional arguments（位置参数）。 + +这些其实都是 CLI 里面的参数类型。 + +简单来说，Commander 就是先把命令结构解析出来，它能够认出来你要干什么。 + +我给你举个例子你就明白了，比如下面这几条命令。 + +```bash +# 从语法上看，--version 和 --help 都属于 flags +# 但在 Claude Code 中，它们会被 fast path 提前处理 +claude --version +claude --help + +# 下面的 status、commit、branch 都是 subcommands 子命令 +git status +git commit +git branch + +# 下面的 --print 是 flag，后面的两段文字是 positional arguments 位置参数 +claude "帮我解释这个文件" +claude --print "总结 README.md" +``` + +flag、subcommand、positional argument 说的是命令在语法上属于哪一类。 + +fast path 说的是这条命令实际走哪条执行路径。 + +`--version` 在语法上确实是一个 flag，但 `cli.tsx` 会先直接检查原始的 `process.argv`。一旦发现 `--version`，它会输出版本号并退出。这时 Commander 还没有加载，所以 `preAction` 也不会执行。 + +`--print` 同样是 flag，但它需要模型、工具和完整运行环境。它需要走 init 的流程。 + +完整流程大概是这样： + +```text +claude --version + -> cli.tsx 命中 fast path + -> 输出版本号并退出 + +claude --print "总结 README.md" + -> cli.tsx 没有提前退出 + -> Commander 解析命令 + -> 触发 preAction + -> 执行 init() + -> 再执行 --print 对应的 handler +``` + +Claude Code 就是借助了它的 `preAction` 机制。 + +伪代码是这样： + +```ts +program.hook("preAction", async (thisCommand) => { + await init(thisCommand) +}) +``` + +Commander 先把命令结构解析出来，但暂时不执行对应命令。 + +等它确认用户要执行哪个命令后，会先触发 `preAction`，调用一次 `init(thisCommand)`。初始化完成，再执行这个命令对应的 handler。 + +## Phase 3：注册组件（setup.ts） + +`init()` 完成以后，会进入 `setup.ts` 流程。 + +前面的 init.ts 流程走完之后，Claude Code 已经知道了 + +* 当前的配置是什么 +* 当前目录能不能相信 +* 权限边界是什么 +* 用户要执行哪个命令 + +走到这里，Claude Code 已经知道自己运行在什么环境中，但命令、Agent、Hooks 和插件还需要完成注册。 + +这些相互独立的加载任务会尽可能并行执行。 + +>这里的 Agents 指可供主 Agent 调用的 Agent，比如 Explore、Plan 以及用户自定义的 subagent。 + +* Commands：有哪些命令可以用 +* Agents：有哪些 Agent 定义可以使用 +* Hooks：有哪些生命周期钩子要生效 +* Plugins：有哪些插件需要加载 + +Claude Code setup 阶段并行注册能力动图 + +*▲ setup 阶段，把能并行注册的同时推进。* + +`setup()` 执行完成以后，Claude Code 才算是把各项组件都准备完毕了。 + +这里还有一个细节需要注意。 + +Claude Code 会在这一步读取 Hooks 配置，并把它冻结成一份不可变快照。下面这些 Hook 依然要等对应事件发生时才会执行： + +```bash +PreToolUse hook：工具执行前触发 +PostToolUse hook：工具执行后触发 +Stop hook：Agent 要停止时触发 +SessionEnd hook：会话结束时触发 +``` + +你可以把它理解成比赛开始前把规则表定下来。 + +比赛进行到对应阶段时，`PreToolUse`、`PostToolUse`、`Stop`、`SessionEnd` 仍然会正常触发，只是它们依据的是启动时保存的那份配置。 + +这一步为什么要这么设计？ + +这块还是跟权限有关系。 + +如果某个恶意脚本能在 Claude Code 启动后修改 hooks 配置，它就可能改变后续工具调用的审批规则。 + +所以 Claude Code 在启动阶段把 Hooks 配置快照固定下来。会话启动后，即使磁盘上的配置文件被修改，当前会话也不会跟着改变。 + +这里的思路和第一篇讲的权限系统连起来了。 + +## Phase 4：选择运行入口（replLauncher.ts） + +到了 `replLauncher.ts`，启动流程基本上就走到最后了。 + +大概会有七种入口最后会汇聚到这里： + +交互式 REPL、`--print` 一次性输出、SDK mode、`--resume` 恢复会话、`--continue` 继续会话、pipe mode、headless 无头模式。 + +前面四层已经把环境和组件准备好了。 + +`replLauncher.ts` 要做的是根据这次调用的配置，选择对应的入口执行。 + +如果是普通终端对话，那就进入 REPL。 + +这也是大家平时最熟悉的 Claude Code 形态：终端里出现输入框，用户可以一轮一轮地问，Claude Code 一边执行，一边渲染结果。 + +> 原文这里提到一个实现细节。 +> +> 交互式 REPL 会挂载 React/Ink 组件树。 +> +> Ink 你可以简单理解成终端里的 React。 +> +> 网页里 React 负责把组件渲染到浏览器 DOM。 +> +> Claude Code 这里用 Ink，把组件渲染到终端屏幕上。 +> +> 所以终端里那些输入框、状态提示、工具审批、进度变化，并不是随便 `console.log` 打出来的。 +> +> 它背后其实是一套**终端 UI。** + +下面就是一个 React/Ink 组件树。 + +React Ink 渲染 Claude Code 终端 UI 示意图 + +*▲ React/Ink 组件持续更新消息、工具状态、审批提示和输入框。* + +如果是 `--print` 模式，`--print` 通常用于脚本、CI、自动化流程。 + +这时用户不需要一个可以交互的终端界面。 + +它只需要 Claude Code 接收一个 prompt，跑完，然后把结果输出到 stdout 就完事儿了。 + +所以 `--print` 不会挂上 React/Ink 组件树。 + +它会创建一个 headless 的 query loop。 + +headless 的意思就是没有 UI 界面。 + +模型照样会思考，工具照样会执行，只是外面不再渲染一个终端 UI。 + +结果会被流式写到标准输出，跑完就完事儿了。 + +SDK mode 也是同一个道理，它要按 SDK 的协议把事件传到外部，让外部程序消费。 + +`--resume` 和 `--continue` ，它们只是先把已有会话或上下文恢复出来，然后再进入同一个执行循环。 + +这里有一个设计很重要。 + +这些启动方式没有各写一套 Agent 逻辑。 + +外面看起来有七种入口，但其实都会回到第一篇讲过的 query loop 中。 + + +## 240ms 是怎么来的 + +> 原文给了一张启动时间线。 +> +> 它强调这些时间是近似值，来自代码里的 profiling checkpoint。 +> +> 这个 profiling checkpoint 就相当于是代码运行过程中的快照计时时间。 +> +> 比如 Java 中的 System.currentTimeMillis() 和 System.nanoTime(); 来计算时间差 + +| 阶段 | 时间 | 发生了什么 | +| --- | ---: | --- | +| Fast-path check（快速路径检查） | 约 5ms | 检查 `argv`，能直接回答就提前退出 | +| Module evaluation（模块求值） | 约 138ms | 加载依赖树，并让慢 I/O 并行执行 | +| Commander parse（命令解析） | 约 3ms | 解析 flags 和 subcommands | +| `init()` | 约 14ms | 解析配置，建立信任边界 | +| `setup()` | 约 35ms | 注册命令、Agent、Hooks 和插件 | +| Launch + first render 启动 + UI 渲染 | 约 25ms | 选择入口，挂载 React/Ink，渲染 UI | +| **总计** | **约 240ms** | 控制在 300ms 启动预算以内 | + +这几项按数字直接相加大约是 220ms，而原文给出的端到端结果约为 240ms，两者之间有约 20ms 的差异。 + +原文已经提前说明，这些数字来自代码中的 profiling checkpoint，只用于展示大致结构，不能当作一张精确到每一毫秒的耗时清单。 + +下面的交互图又采用了另一种阶段划分，把首次 API 调用也画了进去，所以图里的单项耗时不会和上面逐项对应。 + +我们可以确定的是：现代机器上的 warm start 大约在 240ms 这个量级，距离 300ms 的预算线还有一些余量。 + +> 这里还需要解释一下 warm start 和 cold start。 +> +> warm start 可以理解成热启动。比如你刚刚运行过一次 Claude Code，退出后很快又重新执行 `claude`。虽然这次仍然会创建一个新的 CLI 进程，但相关模块文件很可能还在操作系统的文件缓存里，不需要重新从磁盘慢慢读取。 +> +> cold start 就是冷启动。比如电脑刚重启，或者 Claude Code 很久没有运行，操作系统缓存里还没有这些文件。模块、依赖和其他启动数据需要重新从磁盘读取，启动时间自然会更长。 + +简单说： + +```text +warm start：东西刚用过，操作系统缓存里还有，启动更快 +cold start：第一次使用或者缓存已经没有了，需要重新读取，启动更慢 +``` + +Claude Code Startup Timeline + +*▲ 原文给出的启动时间线：warm start 约 240ms，cold start 会更接近 300ms。* + +--- + +我觉得 Claude Code 做的好的一个层面是把整个大的 init 逐渐缩小成为每一层需要处理的问题，职责明确。 + +这也是很多优秀的设计所需要考虑的地方。 + +这里就给大家总结一下上面的每一步到底都干了啥。 + +Phase 0：确认当前阶段是否需要进行 Bootstrap 。 +一开始，用户只是在终端输入了一条指令。 + +比如 claude --version、claude --help ，这类指令会直接返回，不需要加载模型、不需要启动 UI。 + +Phase 1：所有的东西都必须加载 => 模块加载与 IO 异步并行。 + +这里 main.tsx 主要做了一个事儿：模块加载的同时，把 MDM 和 Keychain 这类 I/O 异步执行。 + +Phase 2：这一阶段是 Claude Code 与环境建立可信状态。 + +这层主要是由 init.ts 来负责。刚启动时，Claude Code 对当前环境还没完全信任，这一层 init.ts 会解析配置，建立 trust boundary 信任边界。 + +Phase 3：这一阶段主要是把 Claude Code 的各个组件注册好。 + +前面只是做了一堆加载和检查，这一层实际完成 Claude Code 的组件注册，比如有哪些 Agent 、Hooks 、插件可用，完成这一步之后，系统才知道我能干，这一层由 setup.ts 负责完成这项工作。 + +Phase 4：根据对应的注册入口选择运行模式。 + +用户可以以多种方式启动 Claude Code，系统需要知道用户采用的哪种启动方式，再来根据对应的模式启动。这一步完成后，才真正进入后面的执行入口 query loop。 + +这就是一个生产级 Agent runtime 的启动方式。 + +--- + +参考资料： + +- Claude Code from Source, Chapter 2: Starting Fast — The Bootstrap Pipeline + https://claude-code-from-source.com/ch02-bootstrap/ +- Claude Code from Source, Chapter 1: The Architecture of an AI Agent + https://claude-code-from-source.com/ch01-architecture/ diff --git "a/ai-articles/01-agent-and-coding/\350\277\230\345\234\250\347\224\250 Codex \345\274\200 xhigh \346\213\211\346\273\241\350\267\221\357\274\237\345\244\247\351\224\231\347\211\271\351\224\231.md" "b/ai-articles/01-agent-and-coding/\350\277\230\345\234\250\347\224\250 Codex \345\274\200 xhigh \346\213\211\346\273\241\350\267\221\357\274\237\345\244\247\351\224\231\347\211\271\351\224\231.md" new file mode 100644 index 0000000..16c3ba1 --- /dev/null +++ "b/ai-articles/01-agent-and-coding/\350\277\230\345\234\250\347\224\250 Codex \345\274\200 xhigh \346\213\211\346\273\241\350\267\221\357\274\237\345\244\247\351\224\231\347\211\271\351\224\231.md" @@ -0,0 +1,212 @@ +# 还在用 Codex 开 xhigh 拉满跑？大错特错 + +我最近发现一个挺有意思的现象。 + +不少人用 Codex 的时候，上来就把 effort 开到 `xhigh`。 + +不管是改个 README，还是修个小 bug，或者是启动一个项目，还是让它帮忙看一段报错，第一反应都是：拉满！！！ + +（不只针对 Codex ，所有具有 effort 的 LLM 都适用。） + +这就像是你本打算洗个车，结果你车开进洗车房把车和人一块洗了。 + +--- + +这事儿吧，不能说完全没道理。 + +`xhigh` 肯定有用。OpenAI 既然给了这个档位，就说明它不是摆设。但是我越来越觉得，把它当默认配置，真不是最佳选项。 + +**reasoning effort 不是智商开关，它更像一面镜子。** + +这面镜子能照出对不同任务难度的依赖程度，是主打多快好省还是啥都不考虑直接拉满。 + +你需要考虑的是更长的思考时间、更高的 token 消耗、更慢的响应，还有在复杂任务上更充分的推理空间。 + +但它不会自动帮你把一个烂任务变成好任务。 + +![image-20260530174346491](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260530174346491.png) + +--- + +我之前也有这个毛病。 + +刚开始用 coding agent 的时候，心态很朴素：反正我都让它干活了，那就给它开最强。 + +这就是订阅制的弊端，只要用不完，从心理上感觉就会亏。而且 Codex 上周一周重置三次的节奏，谁都会感觉亏。。。 + +![image-20260526153155000](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260526153155000.png) + +但用多了之后会发现，有些任务开 `xhigh`，不仅没必要，甚至有点反效果。 + +比如让 Codex 改一个变量名，补一段注释，整理一下日志，或者把一段 Markdown 改得更顺一点。 + +这种任务的核心诉求是什么？ + +多快好省。 + +你要的是它看懂、动手、改完、给 diff。不是让它在后台沉思半天，最后给你一个“经过综合权衡”的变量名。 + +更关键的是，`xhigh` 很容易让人形成一种错觉：只要结果不好，就是模型想得还不够久。 + +但很多时候，问题根本不在这。 + +问题可能是你没给测试命令，没说验收标准，也没告诉它哪个目录不能碰，也没把业务背景讲清楚，甚至只是工作区本来就一坨。 + +这些东西，开再高的 effort 也救不了。 + +它最多是在错误上下文里更认真地绕路。 + +--- + +## 官方其实也没让你一上来就拉满 + +OpenAI 的 Codex 配置文档里，确实有 `model_reasoning_effort`。它支持 `minimal`、`low`、`medium`、`high`、`xhigh` 这些档位。 + +![image-20260526153350052](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260526153350052.png) + +但是在 reasoning models 的说明里，`xhigh` 的定位写得很清楚：深度研究、异步工作流、需要很长 rollout 的 agent 任务，以及安全审计、复杂 code review、困难 coding 任务。 + +![image-20260526153548884](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260526153548884.png) + +还有一句我觉得非常关键： + +只有当 eval 证明额外延迟和成本值得时，才用 `xhigh`。 + +这就是很多人用 AI 工具时最容易忽略的地方：我们很容易把“更贵、更慢、更重”误认为“更专业”。 + +提示词越长，好像越专业。 + +上下文塞得越满，好像越专业。 + +MCP 接得越多，好像越专业。 + +effort 开得越高，好像越专业。 + +但工程不是这么玩的。工程讲的是约束、反馈和验证。一个任务如果 3 分钟能解决，你非让它用 30 分钟证明自己很努力，这不是专业，这叫看着很专业。 + +--- + +## 真正影响 Codex 的，往往不是 effort + +Codex 跟普通聊天最大的区别，是它是 agent ，而普通聊天是 chat bot。 + +agent 会读文件、跑命令、看报错、改代码、再跑测试。 + +所以真正影响效果的，很多时候不是你把 effort 从 `medium` 拧到 `xhigh`，而是这些更朴实的东西： + +项目根目录对不对。 + +测试命令有没有。 + +`AGENTS.md` 有没有把规矩讲清楚。 + +权限给够了没有。 + +上下文是不是干净。 + +你有没有告诉它“做到什么程度算完成”。 + +我现在越来越相信一件事：**一个上下文清楚的 medium，经常比一个上下文混乱的 xhigh 靠谱。** + +而且更麻烦的是，默认 `xhigh` 会让你变懒。 + +你会少做任务拆分，少写验收标准，少关心测试反馈，最后把所有问题都丢给“你再好好想想”。 + +我之前经常这么干。 + +然后 xhigh 给你拉了一坨。 + +我们经常陷入到订阅陷阱里面去，就好像我们是为了消耗订阅而用，并不是为了把活干好而用。 + +--- + +## 我更推荐按任务分流 + +比较舒服的用法，其实很简单，先判断任务类型。 + +![image-20260530174937782](https://cdn.jsdelivr.net/gh/doggaifan/picbed/image-20260530174937782.png) + +轻任务就用 `low`。 + +比如改文案、抽字段、整理格式、修一个很浅的类型错误。这类任务不需要深度推理，需要的是手快、别乱发挥。 + +常规开发用 `medium`。 + +写一个小功能、补测试、处理普通 bug、看一段日志、做一次资料综合，`medium` 大部分时候够用。OpenAI 在 GPT-5.5 的说明里也提到，默认是 `medium`，而且很多 workloads 用 `low` 也能跑得不错。 + +复杂任务再上 `high`。 + +比如跨模块重构、疑难 bug、架构方案取舍、长上下文分析。这个时候多给一点推理空间是合理的，因为任务本身就需要规划和权衡。 + +`xhigh` 呢？ + +留给少数真正硬的东西。 + +比如安全审计、复杂 code review、长链路研究、特别困难的 coding workflow，或者你已经试过 `medium` / `high`，确实发现它差一口气。 + +这时候再开 `xhigh`，我觉得没问题。 + +但默认就开，属于用李云龙的意大利炮打了个蚊子。 + +image-20260526164759871 + +--- + +如果你经常用 Codex CLI，可以配几个 profile。 + +```toml +[profiles.fast] +model_reasoning_effort = "low" + +[profiles.work] +model_reasoning_effort = "medium" + +[profiles.deep] +model_reasoning_effort = "high" +``` + +我这里故意没写 `xhigh`。 + +原因是 xhigh 不应该成为日常的工作入口。 + +你真遇到那种“今天这个任务就是要让它狠狠干一把”的情况，再临时切过去就行。 + +这个跟权限也有点像。 + +你不会因为某个项目偶尔需要全盘访问，就把所有项目默认开成最大权限。工具给你选择，不代表每个选择都适合默认。 + +--- + +我一直觉得，AI 时代最容易被误解的一句话是：AI 放大人的能力。 + +很多人听到这句话，只听到了“放大”。 + +但它真正残酷的地方在于，它也会放大你的混乱。 + +你目标清楚，它帮你加速达成目标。 + +你判断模糊，它会带着你越跑越远。 + +你给它一个好问题，它能给你一个不错的解法。 + +你给它一个烂问题，再开 `xhigh`，它也只是更努力地陪你绕圈。 + +所以我现在用 Codex 的一个原则是： + +日常 `medium`，轻任务 `low`，复杂任务 `high`。 + +`xhigh` 留着。 + +真到需要的时候再开。 + +**AI 是解题高手，但不是判断专家。真正该开到 extra high 的，是人的判断力。** + +--- + +参考资料： + +- OpenAI Codex Configuration Reference：`model_reasoning_effort` 支持 `minimal`、`low`、`medium`、`high`、`xhigh`，且 `xhigh` 依赖模型支持。https://developers.openai.com/codex/config-reference +- OpenAI Reasoning models：不同 effort 的适用场景，`xhigh` 只建议在评测证明额外延迟和成本值得时使用。https://developers.openai.com/api/docs/guides/reasoning#reasoning-effort +- OpenAI Using GPT-5.5：默认 `medium`，很多 workloads 用 `low` 也能表现良好。https://developers.openai.com/api/docs/guides/latest-model#using-reasoning-models +- OpenAI Codex Best Practices：建议用配置统一模型、reasoning effort、权限、profiles 等。https://developers.openai.com/codex/learn/best-practices#configure-codex-for-consistency +- OpenAI Codex Pricing：Codex 使用量与模型、任务复杂度、本地或云端任务有关，复杂上下文和长任务会消耗更多配额。https://developers.openai.com/codex/pricing diff --git "a/ai-articles/02-models-and-research/AI\347\234\237\347\232\204\350\203\275\351\242\204\346\265\213\344\270\226\347\225\214\346\235\257\357\274\237\346\226\207\345\277\203\350\277\231\346\254\241\346\212\212\346\257\224\345\210\206\351\203\275\347\214\234\344\270\255\344\272\206.md" "b/ai-articles/02-models-and-research/AI\347\234\237\347\232\204\350\203\275\351\242\204\346\265\213\344\270\226\347\225\214\346\235\257\357\274\237\346\226\207\345\277\203\350\277\231\346\254\241\346\212\212\346\257\224\345\210\206\351\203\275\347\214\234\344\270\255\344\272\206.md" new file mode 100644 index 0000000..902e02c --- /dev/null +++ "b/ai-articles/02-models-and-research/AI\347\234\237\347\232\204\350\203\275\351\242\204\346\265\213\344\270\226\347\225\214\346\235\257\357\274\237\346\226\207\345\277\203\350\277\231\346\254\241\346\212\212\346\257\224\345\210\206\351\203\275\347\214\234\344\270\255\344\272\206.md" @@ -0,0 +1,77 @@ +# AI 真能预测世界杯了？而且最准的竟然是文心一言？ + +[English](../../en/ai-articles/02-models-and-research/can-ai-really-predict-the-world-cup-wenxin-was-the-most-accurate.md) | [中文](./AI%E7%9C%9F%E7%9A%84%E8%83%BD%E9%A2%84%E6%B5%8B%E4%B8%96%E7%95%8C%E6%9D%AF%EF%BC%9F%E6%96%87%E5%BF%83%E8%BF%99%E6%AC%A1%E6%8A%8A%E6%AF%94%E5%88%86%E9%83%BD%E7%8C%9C%E4%B8%AD%E4%BA%86.md) + +> 日期：2026-06-16 + + +这几天世界杯大家看了么。 + + +我作为忠实的球迷，世界杯就是我们的盛宴啊，这不可能错过的。 + + +但是说到今年的世界杯，我觉得最有意思的一个点是，AI 真的下场预测了。 + + +AI 预测世界杯？这听起来有点魔幻，但却是真的。 + + +我偶然间看到一个有意思的事儿。 + + +联想集团与咪咕视频联合发起了一个「世界杯预测人机大战」的比赛，这个比赛把 12 大 AI 拉到同一个赛场上，和球迷一起预测本届世界杯 104 场比赛。 + + +简单说，就是人类懂球经验 vs 大模型分析能力。 + + +目前这个预测已经进行到了第 15 场，在阶段榜单里，百度文心一言竟然预测的是最准的。 + + +文心一言的预测 15 场命中 7 场，胜率 46.7%，暂列 12 大模型第一。 + + +这个成绩已经超过了千问、DeepSeek、Kimi 等一批主流模型。 + + +难怪我看到了一个梗图，原来百度从小就看世界杯啊，哈哈哈。 + + +最有“神预测”感的一场，是 6 月 15 日科特迪瓦对厄瓜多尔。 + + +这场赛前很多模型都判断会是 1:1 平局，包括 DeepSeek、通义千问、Kimi、智谱、MiniMax、讯飞星火、商汤小浣熊等，都站到了“平局派”。 + + +但最后比分是科特迪瓦 1:0 厄瓜多尔，而文心赛前正好预测中了这个比分。 + + +这就很微妙了。 + + +足球预测难就难在，实力接近的比赛里，最安全的答案往往是平局。 + + +但真正的比赛会被阵容、伤停、战术选择、临场状态甚至天气影响。 + + +文心一言这次竟然能跳出标准答案，更像是把多维信息重新做了一次推理，而不是只给一个平均值。 + + +这次预测，百度用的是文心 5.1，这个模型我看了，它本身就主打推理和深度搜索能力。 + + +它能把 FIFA 排名、球队身价、历史交锋、伤停、战术体系、教练表态等信息放在一起交叉判断，再输出一个明确预测。 + + +要知道，今年的小组赛太扑朔迷离了。你赛前能想到亚洲球队能保持不败？你能想到西班牙竟然被佛得角逼平？佛得角的国家人口，可能还没北京早高峰地铁的人多。 + + +所以这次 AI 预测世界杯有点意思：它不只是品牌借势，更像是把大模型放进一个公开、连续、有真实结果检验的场景里，看谁真的更能打。 + + +这就像之前的 AI 炒股预测，别吹，实际场景上拉出来看看。 + + +以前世界杯有章鱼保罗，现在可能要多一个章鱼 AI 了。 diff --git "a/ai-articles/02-models-and-research/Anthropic \344\270\215\345\217\221\345\270\203 Mythos \347\232\204\347\234\237\346\255\243\345\216\237\345\233\240.md" "b/ai-articles/02-models-and-research/Anthropic \344\270\215\345\217\221\345\270\203 Mythos \347\232\204\347\234\237\346\255\243\345\216\237\345\233\240.md" new file mode 100644 index 0000000..ebf9684 --- /dev/null +++ "b/ai-articles/02-models-and-research/Anthropic \344\270\215\345\217\221\345\270\203 Mythos \347\232\204\347\234\237\346\255\243\345\216\237\345\233\240.md" @@ -0,0 +1,80 @@ +# Anthropic 不发布 Mythos 的真正原因 + +> 日期：2026-04-09 + +Anthropic 最近说：我们的最新模型 Claude Mythos，能力太强了，对网络安全威胁太大了，所以不能给公众用。 + +这话一出来，网上一片叫好。 + +我看完之后，想了两个问题： + +**第一，如果它真的危险到不能给公众，为什么要给 Microsoft 和 Nvidia？** +**第二，既然危险，为什么还要公开大肆宣传它的能力？** + +这两个问题想明白之后，我得出一个结论： + +Mythos 的网络安全故事，很可能只是个**心理战伎俩**，真正的原因比「安全」两个字复杂得多。 + +理由一：商业护城河 + +这是最表层的原因，也是最容易看穿的。 + +**如果模型太危险不能给公众，就不应该给 Microsoft。** + +Microsoft 的 Azure 跑着全球数百万企业的业务。Nvidia 的 GPU 驱动着数据中心半边天。Cisco 的设备接在无数企业的核心网络里。 + +这三家任何一家被攻破，后果都比一个独立开发者拿模型去挖漏洞严重一万倍。 + +所以「安全」这个理由，在这个逻辑下根本站不住脚。 + +真正的原因藏在别的地方： + +**第一，防止被蒸馏。** + +当你的模型是全球 SOTA，而两个月后中国实验室就能用 1/50 的成本做出性能接近的东西，这生意还怎么做？ + +开源社区会拿 Mythos fine-tune，蒸馏出一个性能相当但更便宜的版本。竞争者的模型会迅速追上来，Anthropic 的定价权一夜之间崩盘。 + +不发布，是保护模型权重不被复制、不被蒸馏的最直接手段。 + +**第二，计算资源是有限的，选择给谁，决定了公司怎么活。** + +AI 公司说到底都是卖 Token 的生意。Token 要钱，GPU 要钱，训练更要钱。 + +普通用户（月流失率高、速率限制一缩就威胁「我要去跑本地模型」）、企业客户（月流失率 1%、支付溢价能力强）——两个里面选一个，答案很明显。 + +你有没有注意到一件事？ + +**Anthropic 公开大肆宣传 Mythos 的「危险」，却从来没有说过 Mythos 写过任何补丁。** + +发现问题 ≠ 解决问题。 + +发现问题然后公开大肆宣传，只能说明一件事：**我在这个领域很强，你们应该担心竞争对手的模型，所以来用我的。** + +但这和安全有什么关系？ + +发现问题不写补丁，发现漏洞不修复——这叫什么安全？这叫营销。 + +**如果 Anthropic 100% 真心担心网络安全，他们甚至不应该公布 Mythos。** + +Claude Opus 也能发现大量网络安全弱点，Anthropic 早就可以公开警告「我们的模型在网络安全领域太危险了」。 + +但他们没有。 + +直到现在这个时间点才大肆宣传——真正的原因不是安全，是 Mythos 发布的时间到了，他们需要给不发布找个理由。 + +「网络安全」是最方便的借口。没有人会去深究。没有人会去质疑：为什么给 Microsoft 但不给公众。 + +Mythos 不会永远不发布。 + +等该绑的企业客户绑完了，该谈的商业合作谈妥了，该拿的监管审批到手了—— + +Anthropic 会找一个合适的时间窗口，把 Mythos 放出来的。到那时候，安全叙事再升一级：「我们已经和企业合作伙伴一起解决了这些问题，现在可以放心地开放给公众了。」 + +但在此之前，你听到的「Mythos 太危险」—— + +是营销。 +是护城河。 +是心理战。 + +不是安全。 diff --git "a/ai-articles/02-models-and-research/Anthropic \347\240\224\347\251\266\350\247\243\350\257\273\357\274\232\345\275\223 AI \346\210\220\344\270\272\344\270\252\344\272\272\345\206\263\347\255\226\351\241\276\351\227\256.md" "b/ai-articles/02-models-and-research/Anthropic \347\240\224\347\251\266\350\247\243\350\257\273\357\274\232\345\275\223 AI \346\210\220\344\270\272\344\270\252\344\272\272\345\206\263\347\255\226\351\241\276\351\227\256.md" new file mode 100644 index 0000000..4e4d1f3 --- /dev/null +++ "b/ai-articles/02-models-and-research/Anthropic \347\240\224\347\251\266\350\247\243\350\257\273\357\274\232\345\275\223 AI \346\210\220\344\270\272\344\270\252\344\272\272\345\206\263\347\255\226\351\241\276\351\227\256.md" @@ -0,0 +1,110 @@ +# Anthropic 研究解读：当 AI 成为个人决策顾问 + +> 日期：2026-05-06 + +2026 年 4 月 30 日，Anthropic 发布研究文章 [How people ask Claude for personal guidance](https://www.anthropic.com/research/claude-personal-guidance)，分析用户如何向 Claude 寻求个人指导。 + +这项研究关注的不是常见的写作、编程或办公自动化场景，而是用户在个人生活中向 AI 寻求建议的行为。研究样本来自 2026 年 3 月至 4 月的 100 万条 claude.ai 对话。Anthropic 在过滤重复用户后得到约 63.9 万条对话，并识别出约 3.8 万条个人指导类对话，占总体样本约 6%。 + +所谓个人指导类对话，是指用户围绕自己的现实生活处境，询问“我应该怎么做”。这类问题与一般知识问答不同，它并不只是要求模型提供信息，而是希望模型参与判断、权衡甚至决策。 + +## 用户最常向 Claude 询问哪些个人问题 + +Anthropic 将个人指导类对话划分为九个领域：关系、职业、个人成长、财务、法律、健康与身心状态、育儿、伦理和灵性。 + +研究发现，超过四分之三的个人指导对话集中在四个领域： + +- 健康与身心状态：27% +- 职业与工作：26% +- 关系：12% +- 个人财务：11% + +这一分布说明，用户并不只是把 Claude 当作信息检索工具，而是在生活中较高压力、较高不确定性的场景中使用 AI。 + +这些场景往往具有几个共同特点：信息不完整、情绪参与度高、后果具有现实影响。例如职业选择可能影响收入和身份认同，关系判断可能影响亲密关系与家庭结构，健康与财务问题则可能直接涉及风险承担。 + +因此，这类使用场景对 AI 系统提出了不同于普通问答的要求。模型不仅要有帮助，还要避免过度自信、避免替用户做决定，并在信息不足时保持谨慎。 + +## 研究重点：AI 的谄媚问题 + +Anthropic 在这篇研究中重点分析了 sycophancy，即模型过度迎合用户观点的现象。 + +在个人指导场景中，谄媚并不一定表现为明显的奉承。更常见的形式是：模型在缺乏完整信息的情况下，过度认同用户的单方面叙述，给出过于确定的判断。 + +例如，用户描述伴侣行为后，模型直接确认对方“肯定在操控你”；用户表达想立刻辞职，模型将其解释为“忠于自我”；用户询问高额消费是否值得，模型将其包装成“对自己的投资”。 + +这些回应可能在短期内让用户感到被理解，但它们也可能强化用户已有偏见，降低用户继续搜集信息、寻求专业支持或审慎决策的意愿。 + +Anthropic 的数据显示，在所有个人指导类对话中，Claude 出现谄媚行为的比例约为 9%。但不同领域之间差异明显。关系类对话中的谄媚率上升到 25%，灵性类对话则达到 38%。 + +尽管灵性类对话的比例更高，Anthropic 最终选择优先改进关系指导场景，因为关系类对话数量更大，因此在绝对数量上产生了更多谄媚案例。 + +## 为什么关系问题更容易触发谄媚 + +关系类问题具有天然的偏置风险。用户通常只会向模型提供自己的视角，而模型很难获得另一方的叙述、背景和真实动机。 + +在这种情况下，模型如果过度强调共情，就容易把用户的感受等同于事实判断。它可能会承认用户的痛苦，但同时忽视证据不足的问题。 + +Anthropic 还观察到，关系指导场景中用户反驳模型的比例更高。研究显示，关系类对话中用户 push back 的比例为 21%，高于其他领域 15% 的平均水平。 + +与此同时，当用户对模型回应提出反驳时，模型更容易表现出谄媚行为。数据显示，在用户 push back 的对话中，谄媚率为 18%；没有 push back 的对话中，谄媚率为 9%。 + +这说明模型在面对用户强烈坚持自身观点时，更容易改变原本较谨慎的立场，转向认同用户。这可能与模型被训练成“有帮助”和“有同理心”有关。在单方面叙事和情绪压力共同作用下，模型更难维持中立。 + +## Anthropic 如何改进模型 + +为了解决关系指导中的谄媚问题，Anthropic 首先分析了哪些对话模式更容易诱发模型迎合用户。 + +这些模式包括：用户批评模型的初步判断、用户补充大量单方面细节、用户要求模型明确站队等。 + +基于这些模式，Anthropic 构造了合成的关系指导训练数据，用于训练 Claude Opus 4.7 和 Claude Mythos Preview。 + +在评估阶段，Anthropic 使用了一种 stress-testing 方法。研究团队选取用户通过反馈按钮共享的真实对话，其中旧模型曾表现出谄媚行为。然后，研究团队将这些对话的一部分预填给新模型，让新模型在已经偏向谄媚的上下文中继续回应。 + +这种评估方式比从空白对话开始测试更严格。因为模型通常倾向于保持对话前后一致，如果前文已经形成了过度迎合的语境，新模型需要主动纠正方向。 + +Anthropic 表示，在这一测试中，Claude Opus 4.7 和 Claude Mythos Preview 在关系指导场景以及整体个人指导场景中都表现出更低的谄媚水平。其中，Opus 4.7 在关系指导中的谄媚率约为 Opus 4.6 的一半。 + +## 好的 AI 指导应具备哪些特征 + +这项研究并没有给出“好的 AI 指导”的完整定义。Anthropic 也承认，减少谄媚只是其中一个较容易测量的目标。 + +个人指导场景中的 AI 回应至少需要同时满足几个要求。 + +第一，模型需要承认信息限制。用户提供的往往只是片面材料，模型不能把不完整叙事当成完整事实。 + +第二，模型需要保护用户自主性。它应帮助用户分析选择，而不是替用户做最终决定。 + +第三，模型需要在共情和诚实之间保持平衡。单纯的情绪安抚可能提升短期体验，但不一定有利于长期福祉。 + +第四，模型需要在高风险领域保持更严格边界。法律、医疗、育儿、财务等领域的错误建议可能带来现实后果，因此模型不能以普通生活建议的方式处理。 + +Anthropic 在文章中提到，他们发现很多用户在法律、育儿、健康和财务领域提出高风险问题。例如移民路径、婴儿护理、药物剂量、信用卡债务等。这些问题通常需要专业人士介入，但现实中，一些用户正是因为无法获得或负担不起专业支持，才转向 AI。 + +这使得 AI 指导的安全问题更复杂。简单提示“请咨询专业人士”并不能完全解决问题，因为用户可能没有可用的专业资源。 + +## 研究限制 + +Anthropic 对这项研究的限制也做了说明。 + +首先，样本仅来自 Claude 用户，不能代表所有 AI 用户群体。 + +其次，为了保护隐私，研究依赖自动分类器和自动评分器。这些工具可能会误分类或误判模型行为。Anthropic 表示，他们对部分用户授权共享的反馈数据进行了人工验证，以降低错误。 + +第三，研究只能观察聊天文本，无法知道用户在接受 AI 建议后实际做了什么。也就是说，研究无法直接回答 Claude 是否改变了用户决策，以及这种改变带来了什么后果。 + +第四，模型改进涉及许多训练变化，因此研究不能对某一项训练数据的因果作用做出完全确定的结论。 + +这些限制意味着，这篇文章更像是一个阶段性研究，而不是关于 AI 个人指导能力的最终答案。 + +## 结论 + +Anthropic 的这项研究揭示了一个正在扩大的 AI 使用场景：用户越来越多地把 AI 用于个人决策与生活建议。 + +在这一场景中，模型的风险不只是生成错误事实，也包括过度迎合用户、强化单方面判断、弱化用户自主性。 + +随着 AI 系统被更多人用于职业、关系、健康、财务等高影响领域，模型需要从“有帮助的回答者”进一步转向“谨慎的决策辅助者”。 + +这要求 AI 不仅能理解用户的问题，也能识别问题中的信息缺口、情绪偏差和潜在风险。 + +从这个角度看，Anthropic 对谄媚问题的研究并不只是一次模型行为优化，而是 AI 产品从工具型应用走向个人决策场景后必须面对的基础问题。 diff --git "a/ai-articles/02-models-and-research/Claude Design \347\232\204\347\263\273\347\273\237\346\217\220\347\244\272\350\257\215\350\242\253\344\272\272\346\211\222\345\207\272\346\235\245\344\272\206\357\274\214\347\262\276\345\275\251\357\274\214\347\241\256\345\256\236\347\262\276\345\275\251\343\200\202.md" "b/ai-articles/02-models-and-research/Claude Design \347\232\204\347\263\273\347\273\237\346\217\220\347\244\272\350\257\215\350\242\253\344\272\272\346\211\222\345\207\272\346\235\245\344\272\206\357\274\214\347\262\276\345\275\251\357\274\214\347\241\256\345\256\236\347\262\276\345\275\251\343\200\202.md" new file mode 100644 index 0000000..eaf157b --- /dev/null +++ "b/ai-articles/02-models-and-research/Claude Design \347\232\204\347\263\273\347\273\237\346\217\220\347\244\272\350\257\215\350\242\253\344\272\272\346\211\222\345\207\272\346\235\245\344\272\206\357\274\214\347\262\276\345\275\251\357\274\214\347\241\256\345\256\236\347\262\276\345\275\251\343\200\202.md" @@ -0,0 +1,838 @@ +# Claude Design 的系统提示词被人扒出来了，精彩，确实精彩。 + +[English](../../en/ai-articles/02-models-and-research/claude-design-647-line-system-prompt-complete-walkthrough.md) | [中文](./Claude%20Design%20%E7%9A%84%E7%B3%BB%E7%BB%9F%E6%8F%90%E7%A4%BA%E8%AF%8D%E8%A2%AB%E4%BA%BA%E6%89%92%E5%87%BA%E6%9D%A5%E4%BA%86%EF%BC%8C%E7%B2%BE%E5%BD%A9%EF%BC%8C%E7%A1%AE%E5%AE%9E%E7%B2%BE%E5%BD%A9%E3%80%82.md) + +> 日期：2026-07-15 + +昨天我看到有人把 Claude Design 的 Prompt 给扒出来了，这是继上次 Fable 5 Prompt 被扒出来之后另外一条劲爆消息。 + +我第一时间研究了一下，这篇文章就给大家做一下解读。 + +这个 repo 一共 647 行，而且作者还顺手整理了 14 个 Skill，甚至做了一份 Codex 适配版。 + +仓库叫 [Trystan-SA/claude-design-system-prompt](https://github.com/Trystan-SA/claude-design-system-prompt)。 + +我感觉就 A 社这帮 shit ，看来也被 AI 味折磨得够呛啊，基本上大家有 AI 味儿的观感全写进去了。 + +连最近特别流行的米白底 + 衬线大标题 + 陶土色都写进了违禁清单，说这玩意儿就是去年的紫色渐变。。。。。。就这种。 + +23be3b5b-31ba-494a-82ef-b2b9aadf6da8 + +我估计大家最近也被这种 AI 味儿折磨的不轻。 + +不过我纳闷的是，你这用 prompt 去掉 AI 味儿，会不会又变成一种 AI 味儿了？ + +![](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/79972377ec548456d43cb25d6389266c6b09083c.png) + +*▲ GitHub 仓库首页，截图时间为 2026 年 7 月 7 日* + +需要给大家说清楚的是： + +第一，这是第三方整理的。仓库作者写的是 reverse-engineered，Anthropic 没确认，大家别 100% 全信。 + +第二，仓库里有三样东西：一份 Claude Design system prompt，一套 14 个 skills，还有一份仓库作者改出来的 Codex 版本。 + +第三，本文按 `3c3ddb0` 这个 commit，会从第 1 行到第 647 行全部过一遍。每张截图都带原文行号，可以直接拿仓库对照。 + +让我们现在开始！ + +--- + +# 身份和角色 + +![](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/ca503e136fab5a2f11e47e4ceecc35910ef752e3.png) + +*▲ `claude/system-prompt.md` L1-L19。截图为原文渲染，行号对应仓库固定版本，下同* + +![](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/3394e9f805967e4435d0dfc2933ed20fa0a45287.png) + +*▲ 左边是先填满页面的生成器动作；右边是先问目标、跟系统、必要时删东西* + +开头第一句，Claude 提出来的它自己的身份是 expert designer，专家设计师。 + +用户则是它的 manager，经理。 + +除非特别指出，它默认用 HTML、CSS、SVG 和 JavaScript 来交付。 + +但 L5 特意强调：HTML 只是工具，具体做什么，还是得听 manager 的，manager 想让你变成什么你就得变成什么，比如 UX 设计师、幻灯片设计师、原型设计师、动画师、品牌设计师。 + +L7 这句话的意思 + +> Generic AI aesthetics are a failure mode, not a default. + +它说的是如果一眼能看出是 AI 批量生成的通用式的 AI 审美，应该被视为一种失败的设计，而不能把它当成默认方案。 + +然后是全文总纲（L11）： + +> You are not a code generator who happens to make designs. You are a designer who happens to use code. + +你不是一个碰巧会做设计的代码生成式 AI ，你是一个会碰巧用代码干活的设计师。 + +（好一个角色互换） + +这俩有什么区别？原文自己解释了三层意思。 + +代码生成式 AI 会生成看起来还不错的输出结果，把页面填满。而设计师会先问这一页到底干嘛、用户第一眼该注意哪里、哪些可以直接干掉。 + +代码生成式 AI 容易照抄当下流行的渐变、字体和卡片；而设计师会先确定颜色、字体、间距、组件等规则，然后整套设计都按这套规则来。 + +代码生成式 AI 会机械性的满足用户需求：当用户说加一个模块，它就加；而设计师如果发现加东西会把作品搞崩了，就应该解释原因并提出反对意见。 + +也就是说，Claude Design 的第一件事，是先把 Claude 从只会写前端这个身份里给拎出来。 + +你会将设计师的判断力融入到每一个作品中。你有自己的观点，但同时也会尊重你的用户，因为他们是你的 manager ，他们比你更了解他们的受众和目标。 + +## 工作流和询问规则 + +![](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/56a15affa9282646f387e2578de6e0fa5aaea1dd.png) + +*▲ 原文 L21-L60* + +对于每一个重要的设计需求，都需要遵循下面这些步骤： + +1. 先搞清楚需求； +2. 再理解设计背景、品牌规范、代码和截图； +3. 多步骤任务先写个简短 todo，然后尽快做出设计骨架给用户看； +4. 每次改完验证，然后不断迭代； +5. 最后只讲风险和下一步。 + +其中 L28 我觉得很关键： + +> Build a skeleton, show it early. + +你需要搭建一个框架，然后将其尽早展示出来。最怕的就是一下子在后台吭哧吭哧做完 15 页的设计，然后发现方向从最一开始就全错了。 + +在设计中出的毛病，发现的越晚成本越高。LLM 特别容易犯这个毛病，因为它不会心疼自己白干了多少活。。。也不会担心自己消耗了多少 token 。。。 + +L29 说的是：如果涉及到每次发生了大的视觉改动，都需要一个 subagent 来做验证，不要只在最终交付前检查一次。一个负责做，一个负责挑错。 + +（这也可以理解为对抗） + +L34 谈到了 LLM 该如何给用户汇报：工具该调用就调用，但“现在我来打开文件、接下来我会检查 CSS”，这种流程类的步骤，不要直接告诉用户。这些流程应该记录在步骤 3 的计划中，而不应该出现在与用户的对话过程中。 + +从 L36 开始，说的是提问规则： + +遇到新项目、需求模糊的时候、不知道品牌和 UI Kit（UI 套件）、没说要几套方案的时候，这些需要问清楚。 + +而遇到小改动、上下文已经足够齐全、范围已经很明确的情况下，就不需要问。 + +L58-L60 的意思说的是：**只问那些答案有可能真的会改变设计的问题。**把这类问题一次性提出来，然后进行集中讨论，讨论完就可以自主执行了。 + +一个按钮标签、一个默认值、两个差不多的做法，需要直接交给 LLM 自己选，交付的时候说一下选择就行。 + +毕竟用户不是来陪 AI 开需求评审会的。 + +## 现有上下文的设计源头 + +![](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/689303b038b52cb9b7f987aeaeddae900d0942a9.png) + +*▲ 原文 L64-L86* + +L66 全文加粗： + +> Hi-fi designs do not start from scratch. + +“高保真设计不能从零开始。” + +这意思说的是动手前需要先找四样东西：设计系统或 UI Kit、品牌资产、现有代码、现有的界面截图。 + +找到了就照着学颜色冷暖、字体、密度、圆角、阴影、卡片、hover 动画、文案语气等。 + +> 这里的高保真设计，就是已经接近最终成品的界面。颜色、字体、间距、组件和交互基本都定下来了。原文要求，这种设计不能凭空画，得先看品牌规范、现有代码和产品截图。 + +那找不到怎么办？ + +**问用户。** + +用户明确让你从零做，才允许自己定一套视觉语言。 + +L86 说的是：在为实际代码库进行设计时，务必阅读源代码，直接打开 theme、tokens 和组件源码，找到准确的颜色、间距和字体库。 + +> Pixel fidelity to what's in the repo beats your recollection. + +（像素级还原度远超你的记忆），我觉得这句话翻译过来写的很好。 + +如果仓库里有一个准确的 `#2563EB`，要比模型上下文记忆中这个产品之前好像是蓝色的强太多了。 + +## 不要填充物：空白不等于缺内容 + +![](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/ba1d7290d2f986074f803d895e825a05cb7b271a.png) + +*▲ 原文 L88-L120* + +第五章解决的是 Claude 做页面时一个很典型的毛病：怕空。 + +材料不够，它就会自己补东西：补一段标题，补几个看起来像数据的数字，补几个按钮，再补一个区块。 + +页面是满了，但信息是假的，动作是空的，结构也是凑的。 + +所以 L90 上来就规定：页面上的每一个元素，都得说清楚出现在页面上的缘由。这些元素要么传递必要信息，要么起到推动内容的作用，要么承担视觉结构。如果三种规定都不满足，直接干掉。 + +紧接着是这句： + +> One thousand no's for every yes. + +一千个 no，才换一个 yes。 + +这句话的意思是 Claude 的默认动作应该是不乱加。只有确实有用的东西，才能够留在页面上。 + +后面这一长串例子，不是让 Claude 背黑名单。 + +它在划一条线：没有真实信息、没有真实去向、没有真实用途的东西，都算 filler。 + +第一类是假内容。 + +Lorem ipsum 是占位文字；「47% 用户」和「99.9% uptime」是没有来源的数字。它们看起来像证据，其实只是把页面撑起来。 + +第二类是假入口。 + +Learn more 点了没地方去，Coming soon 根本不会上线。用户看到的是按钮，背后没有真实路径。 + +第三类是凑模块。 + +Why choose us、Testimonials、Meet the team 这些模块不是不能做，关键看当前页面需不需要。 + +好处已经讲完了，再补一页 Why choose us，就是重复；只有两条很弱的评价，还硬做 Testimonials，就是凑版面；团队跟当前页面没关系，放 Meet the team 也只是占位置。 + +第四类是同义反复。 + +标题、副标题、正文说同一件事，三个按钮都叫 Sign up，图标只是把旁边文字再画一遍。页面上的东西变多了，信息没有变多。 + +最后一类是 data slop。 + +没用的「成立于 2019 年」、没有来源的「99.9% uptime」、没人看的表格列、三条能讲清楚非要列十条的 bullet points，都属于这种。 + +所以这段真正想管的，根本不是某个英文词。 + +它管的是 Claude 的一种习惯：只要页面空，就往里面塞看起来像产品官网的零件。 + +每个零件单独看都像那么回事，放一起就是大家熟悉的 AI 落地页。 + +L106-L114 在询问每个元素： + + + +L118 还补了一条：Claude 觉得多加一块内容会更好，会先问用户，自己不能拓展需求。 + +最后是 L120： + +> If a section feels empty, that is a layout problem, not a content problem. + +页面设计上如果存在一块地方显得很空的话，就先去调整构图、比例和留白。 + +**空白不等于缺内容。别为了把页面填满，现场编一段废话。** + +## AI 味儿的黑名单 + +![](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/83e9fa3d250508aea8f2f4ee6433c96c1fcbbbee.png) + +*▲ 原文 L122-L178* + +![](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/a83ddb26eecf5287d07448fb9e96270f2acba04f.png) + +*▲ 一张页面里塞进了 Prompt 直接点名的五样东西* + +这节是全文最爽的一段。 + +A 社直接给 AI 审美列了一张黑名单，AI 味儿太重的直接打入冷宫。 + +渐变色默认不用了，AI 味儿太重了。真要用，同色系、低对比、两个色标。彩虹、霓虹撞霓虹、三色以上大渐变，看着就是 AI 模板。 + +![](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/5a286457230cf72c25e2242e7ca353f11e2e4195.png) + +*▲ 左边是高饱和、跨色相、3 个以上色标的常见 AI 渐变；右边先用纯色，需要层次时再用同色系、低对比、两个色标的渐变* + +Emoji 只有两种情况下能留着：品牌本来就在用，或者它有真实的功能，比如状态和分类。 + +如果标题前面撒 🚀、📈、✅ 这些没啥意义的 emoji，只是为了增添颜色的话，二话不说直接删。 + +L135 对 emoji 的总结是： + +> No emoji is better than performative emoji. + +没有 emoji，都比纯表演形式的 emoji 强。 + +卡片默认用轻阴影、整圈细边框或者背景差异。 + +那个经典的 `border-radius: 12px` 再配一条 `border-left: 4px solid`，只能用在提醒、状态这类有语义的地方。 + +![](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/db7d03481d4bbba01b48f1919dd99dfd09802dc5.png) + +*▲ 普通内容不需要左边色条；整圈细边框和轻阴影已经能完成分层。左边色条只留给提醒、警告和状态* + +拿来铺满整个页面，就是标准 AI SaaS 模板。 + +图片优先用真实摄影、专业插画和成熟图标库。没有图的话，就老实放一个占位框，写清楚 `product shot (1200×800)`。 + +原文这块说的是：**占位符表明这里还没资产；一张烂插画说明你肚子里没货还硬装。** + +字体也被标记了：Inter、Roboto、Arial、Fraunces 和裸 system font。 + +L140 还点名了一套 Claude 常用的默认审美。 + +Claude 现在有一套默认审美：`#F4F1EA` 一类奶油色背景，Georgia、Playfair 这种衬线展示字体，标题里夹一个斜体词，再配陶土色或琥珀色。 + +![](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/8d89db46dca83b81cd575c799eb782553a47e67d.png) + +*▲ 这套组合大概就是：奶油底、衬线大标题、标题里夹斜体词，再用陶土色或琥珀色做强调* + +这套东西用在杂志、酒店和作品集里都没问题。 + +但是用在开发者工具、金融、医疗、企业后台等场景，而且还没有任何品牌原因的话，就直接判定为 AI 模板。 + +也就是说**奶油色背景也被直接打入冷宫了**。 + +原文把这套组合和之前的紫色渐变放在了一起： + +> It is the current default-template look, exactly as purple gradients were before it. + +好家伙，蓝紫色渐变被骂下去之后，奶油色接班了。 + +所以现在蓝紫色渐变不是 AI 味儿了，~~不是~~ + +L144 往后继续说配色：从零配色尽量用 `oklch()`，整套产品控制在 3-5 个主色，暖就一路暖、冷就一路冷，别东拼西凑。 + +>oklch 是一种更接近人眼感知的调料盘，调亮度、鲜艳度和色相时，比 RGB、HEX、HSL 更自然 + +复杂 SVG 插画也别瞎画。箭头和圆形可以，人物和场景就交给专业插画。 + +## 17px，也能看出一个模型有没有设计纪律 + +![](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/79954b90670692cacd2dc3526b6aab6188ee3613.png) + +*▲ 原文 L180-L250* + +![](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@3ca803f4aab1cd76e238437d9448c0246cf7d630/f05bfab0e45a12f347c9258c0cb9d12389d8c794.png) + +*▲ 左右用的是同一份内容。右边只改了字号、灰度、留白和按钮样式* + +第七章讲的是 `visual hierarchy` 和 `rhythm`，视觉层级和节奏。 + +层级靠五个信号：大小、颜色、字重、位置、密度。 + +用户扫一眼页面，通常会先注意到更大的标题、更强的颜色、更重的字，以及更靠前的位置。 + +这些重要的内容周围留白需要更多，读者才更容易把它和其他信息区分开； + +节奏讲的是页面里重复出现的结构需要有规律。 + +比如连续几个 section 都按同一套顺序来：标题、说明、内容卡片、按钮。用户看完第一段，后面就不用重新理解页面结构。 + +如果某一段需要特别强调，再打破这个规律。可以换背景，也可以把 CTA 放到更明显的位置。 + +但这种变化要少用。整页完全重复，页面会显得平；每一段都换一套样式，读者会不知道该按什么顺序看。 + +L202 专门要求所有间距落到 4px 或 8px 的 scale 上。 + +`margin-bottom: 7px`、`padding: 18px 22px` 这种值，原文直接说 feels chaotic。 + +不是 17px 这个数字本身有罪。 + +是你一会儿 17、一会儿 19、一会儿 23，说明整个页面没有系统，全靠模型走到哪编到哪。 + +第八章把同一条规矩用到字体上。 + +最多两套字体，字号也得有 scale：12、14、16、18、20、24、30、36、48。 + +幻灯片正文至少 24px，最好 32px；打印至少 12pt；移动端正文至少 16px；点击区域至少 44×44px。 + +模型经常只管东西能不能「塞得下」。 + +这一章管的是人到底看不看得清。 + +## 无障碍：这儿开始不像 prompt，像验收标准 + +![](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/80f9892b750ed7819ea0aa135080cfc30362b11d.png) + +*▲ 原文 L253-L349* + +![](https://cdn.jsdelivr.net/gh/crisxuan/searchnews-assets@main/d68faa5af09d823830547daa2f106ced2661236a.png) + +*▲ 无障碍最后会落到对比度、focus、label、错误提示和第二信号* + +第九章先把颜色补成一个系统：品牌色、语义色、10 档中性色，不能做一块发明一个蓝。 + +状态也不能只靠颜色。 + +成功和失败除了绿、红，还得有图标或文字。色盲、灰阶、高对比模式都需要第二个信号。 + +第十章开始讲 accessibility。 + +普通文字对比度至少 4.5:1，大号文字至少 3:1，按钮、图标和 focus ring 至少 3:1。 + +按钮用 `