editorial-manifesto/），确定首页、Projects、Writing、Tools 的结构和视觉语言。dist 输出），首页和各详情页可公开访问，旧 Markdown 兼容链接保留。v0.2 把主站部署到 Cloudflare Pages：
anchor-ai-lab-astronpm run builddistmain部署后验证：首页、Projects（ace / temucanvas / ai-ppt-workflow）、Writing（三篇）、Tools（ai-tool-reviews）、旧 /docs/AI_TOOL_REVIEWS.md 兼容链接全部 200。明确不做 CMS、后台、数据库、阅读量、评论。
v0.3 的核心判断是：问题不在视觉或架构，而在内容密度。多数页面只有 1-2 段占位摘要，外部访问者能知道“这是什么”，但难以理解“为什么重要、做到哪一步、下一步怎样”。
审计把每个页面按状态 / 问题 / 优先级列成表，给出建议动作。优先级排序：
明确不做：不改首页布局/视觉、不加 CMS/评论/统计、不扩展路由、不把 DOCX 原文整段搬入、不把 TemuCanvas 写成对外产品官网。
v0.4 判断站点已适合作为公开个人 AI 实践站继续迭代，最该补的是公开上线基础要素，而不是继续大改内容或视觉。
审计发现的缺口：
html lang 建议从 zh 改 zh-CN；favicon 没指向实际文件。robots.txt 和 sitemap.xml–线上访问它们都返回首页 200，不是真实文件；不存在路径也返回首页 200，缺真实 404。src/pages/404.astro。v0.4 第一批最小修改：补 Layout.astro 的 meta（title/description/canonical/og/twitter）、详情页传页面级 description 与 canonical、新增 robots.txt + sitemap.xml、新增最小 404 页、补 README 部署信息。明确不做 CMS/后台/阅读量/评论/搜索/多语言/复杂动画/重新设计视觉。
主站和 Blog 解耦各自演进：主站做品牌入口与项目展示，Blog 做长内容与方法论。两边都在 Cloudflare Pages，独立部署。
]]>本文正文待补（v0.2）：结构已就位，待有真实视频工作流经验后补齐，不预先编造。
TemuCanvas 是面向 POD 帆布画 / 框画场景的图像自动可用性系统。
它不是单纯的图片处理脚本，也不是一次性批处理工具。它关注的是商品图输入之后，如何自动识别可用候选，如何判断图像是否适合进入后续流程，如何保留人工复核和错误放行控制，并把失败样本纳入持续改进。
更准确地说，TemuCanvas 是一个围绕真实业务图像建立的找图与可用性判断项目。
POD 商品图处理不是简单的“把图片裁一下”。
真实输入里会出现多目标、规格图、低置信度样本、边缘残留、画框边界、背景干扰、裁切偏松或主体识别失败等问题。如果只依赖单个脚本自动输出，很容易把错误结果放进生产链路。
TemuCanvas 的核心目标不是追求完全自动化，而是建立一套“尽快可用、保留人工兜底”的图像处理流程：自动生成候选，自动分流风险，人工复核不确定样本，失败样本进入下一轮改进。
脚本只解决局部动作，系统要解决流程问题。
TemuCanvas 关注的不是单张图怎么处理得更漂亮，而是一个批次进入后，如何让结果可追踪、可复核、可回滚、可继续改进。因此它会关注输入目录、模型版本、候选输出、分流结果、人工复核、失败样本、批次记录和冻结基线，而不仅是图像处理算法本身。
当前公开层面可以概括为几个阶段：
这个流程的重点是可控，而不是盲目追求“全自动”。
TemuCanvas 的判断重点不是“有没有生成图”，而是“这张图能不能进入真实工作流”。
一个结果可能主体正确但边缘有轻微问题，也可能模型不确定但仍然有参考价值，还可能看似成功但裁错主体。不同情况需要不同处理方式。因此项目会把结果拆成不同层级：可作为交付候选的结果，需要逐张确认的结果，需要人工判断的 review 样本，以及应隔离保存的 hard cases。这种分流机制比单纯的成功 / 失败更适合真实项目。
TemuCanvas 不假设自动输出永远可信。
人工复核不是低效补丁，而是当前阶段必要的质量阀门。对于多目标图、规格图、低置信度样本、明显裁错或主体缺失样本，系统应该停止自动放行，交给人工判断或进入失败样本池。错误放行控制的目标是：宁可把不确定样本拦下来，也不要让错误结果无声进入后续生产链路。
TemuCanvas 是 ACE 在图像处理场景里的实践样本：
TemuCanvas 已有较多历史探索和生产流程积累，但在 Anchor AI Lab 里仍以 Building / Draft 状态呈现–公开站点沉淀的是项目方法和可复用经验，而不是直接公开完整生产系统或内部路径。
后续三个方向：公开版项目说明（边界与不做什么）、流程复盘（候选生成 / 复核 / 放行 / 诊断 / 冻结的可复用方法）、Skill 沉淀（把反复有效的图像 review、批次验收和 hard case 处理沉淀为 ACE Skill）。
]]>本文正文待补（v0.2）：结构已就位，待有真实使用经验后补齐，不预先编造。
一份有效的 PPT 不只是页面好看。它需要清晰的判断路径、足够的证据、合适的视觉强调、稳定的叙事节奏和可交付的导出结果。如果一开始就让 AI “生成一份精美 PPT”，内容、结构和视觉往往会同时失控。
AI PPT Workflow 的核心原则是：每一阶段都先冻结上游产物，再进入下游。内容没有确认，不做大规模设计；风格没有锁定，不批量生成页面；页面没有完成，不急着加动效。
当前流程可以概括为五轮：
正式制作前先做任务预检：PPT 目的是什么，目标观众是谁，核心结论是什么，预计页数是多少，演示场景是现场讲、发给别人阅读、路演还是培训，必须使用哪些素材，禁止出现哪些内容。这一步看起来慢，但可以避免后续反复返工。
PPT 的核心不是把资料放上去，而是帮助观众理解一件事，并基于理解形成判断、做出决定或采取行动。
因此 AI 需要先参与内容重组：把论文、报告、文章或零散资料重组成适合演示的逐页文案，明确每一页承担什么信息任务–哪些页面负责建立问题，哪些负责给出判断，哪些负责展示证据。逐页计划冻结后，才适合进入视觉和制作阶段。
很多 AI 生成 PPT 的失败来自风格漂移。如果没有先确定视觉语言，后续每一页都会重新猜一次风格，结果就是单页看着还行，整套放在一起不统一。
AI PPT Workflow 会先确定视觉方向、字体、色彩、版式密度、图表语言、素材类型和禁止事项，再开始批量施工。视觉系统不是为了装饰，而是为了让信息表达稳定。
我更倾向于先验收静态版，再做动效增量。静态版必须先解决几个问题：内容有没有错，结构是否顺，页面是否可读，风格是否一致，图表和素材是否可信，是否存在假数据、错 Logo、字体错位、文字溢出或导出失真。如果静态版还没有站稳，动效只会把问题放大。
AI PPT Workflow 不盲目追求某一种最终格式。HTML / CSS 工件适合保留真实页面结构和局部交互；PDF 和图片更容易保持视觉效果；PPTX 适合后续继续编辑，但可能出现字体、布局或动效差异，必须单独验收。导出格式要服务于使用场景：现场演示、发给别人阅读、继续编辑、网页展示或长期归档，应该采用不同的交付方式。
动效不是第一步，也不是每页都需要。只有当静态版已经通过验收，且动效确实能帮助讲解、聚焦或节奏推进时，才进入动效增量施工。动效增量也需要受控：先做关键页，先做低风险交互，先验证导出效果，不把所有高级能力都塞进一套 PPT。
AI PPT Workflow 是 ACE 在内容生产场景里的实践样本：
它目前仍处在 Building 阶段，更适合先沉淀为项目说明和方法摘要，而不是包装成成熟产品。
]]>很多人用 AI 做项目，习惯把一个任务完整丢给一个 Agent：让它分析，让它写代码，让它测试，让它总结，最后让它告诉你“已经完成”。这个方式在简单任务里没问题。
但只要项目稍微复杂一点，问题就会出现：它会顺着自己的思路一直往下改，写完之后自己检查自己，很容易看不出问题。它可能遗漏边界条件，误判环境，跳过验证，把没有跑通的东西说成已经完成。
这不是某个模型的问题，而是单 Agent 工作模式天然存在的问题。真实项目里，一个人写完代码还需要别人 code review，一个方案做完还需要别人质疑，一个系统上线前还需要测试验证。AI Agent 也是一样。如果一个 Agent 从头到尾自己做、自己验、自己宣布完成，复杂任务里的风险就会被隐藏起来。
一提到 Agent 协作，很多人会想到复杂的自动化平台、任务队列、多 Agent 框架、自动调度系统。但我现在更认可一种轻量方式：不急着做复杂编排，先让不同 Agent 在真实项目里承担不同角色。
比如：一个 Agent 做方案，一个 Agent 做施工，一个 Agent 做审查，一个 Agent 做验证，一个 Agent 做总结沉淀。这不一定需要复杂系统。很多时候，只要任务边界清楚、文件改动清楚、版本记录清楚，不同 Agent 就可以通过很简单的方式协作。对个人项目来说，最重要的不是搭一个宏大的 Agent 平台，而是先把最小有效协作跑通。
我现在更常用的方式是：ChatGPT 做总工判断，Codex / Claude Code 做施工或审查，WorkBuddy 负责本地执行辅助，Git / Jujutsu 作为版本事实层。这不是固定绑定，而是一种常见分工。
ChatGPT 更适合做需求整理、架构判断、任务拆解、风险识别、验收标准设计、文章与文档整理、项目复盘和 Skill 沉淀。我通常不会让它直接承担所有施工，而是让它先帮我判断：这个任务到底该不该做，怎么拆，风险在哪里，哪些地方需要验证，哪些地方可以轻量处理。它更像是一个总工、产品经理、复盘者和方法论整理者的组合。
Codex 更适合承担比较明确的代码任务。比如修一个具体 bug、改一个具体模块、按要求补一个脚本、重构某个局部功能、生成测试或辅助工具、根据既定方案做实现。
我更倾向于给 Codex 明确边界：这次只改哪些文件，不要扩散到哪些模块，完成后跑哪些验证，不要重构无关逻辑，不要因为找不到依赖就重新安装一套环境。这样 Codex 更容易稳定发挥。
Claude Code 更适合处理一些复杂工程任务，尤其是需要读上下文、理解项目结构、做多文件修改或进行独立审查的时候。它可以承担较复杂的代码施工、多文件影响分析、对 Codex 改动进行审查、检查任务是否真的完成、找出遗漏和边界问题。
我比较看重 Claude Code 的一个用法是：让它换角度检查另一个 Agent 的工作。一个 Agent 写，一个 Agent 审，这种方式非常轻量，但效果往往很好。
WorkBuddy 更适合处理和本地 Windows 环境相关的任务。比如执行脚本、整理目录、收集日志、打包文件、跑本地验证、辅助检查路径、环境和依赖。它不一定负责架构判断，但非常适合作为“真实环境里的执行助手”–因为很多 AI 工程问题，最终都要落到本地机器上验证。
很多人讨论 Agent 协作时，会把重点放在工具强弱上。哪个模型更强，哪个 IDE 更好，哪个 Agent 框架更先进。这些当然重要，但在真实项目里，我觉得更关键的是：所有 Agent 是否围绕同一个任务事实工作。
如果任务事实不清楚，不同 Agent 只会各说各话。所以我会尽量明确几件事：本次任务目标是什么，不做什么，涉及哪些文件，当前可信环境是什么，正式入口是什么，哪些验证必须跑，哪些结果算完成，哪些失败必须停下来反馈。只要这些事实清楚，不同 Agent 就可以轻量协作。如果这些事实不清楚，即使上再复杂的 Agent 框架，也只是把混乱自动化。
我现在越来越重视版本事实层，因为聊天记录不适合作为工程事实。
Agent 说它改了什么，不如直接看 diff。Agent 说它完成了，不如看 commit 和验证结果。Agent 说它只改了一个地方，不如看实际文件变更。这也是为什么 ACE 里会采用 Jujutsu + Git 的路线：Git 是通用事实层，负责 commit、diff、历史记录、回滚、审计和跨工具协作；Jujutsu 更适合本地施工过程，负责本地变更整理、工作区管理、撤销和调整提交。在 Agent 协作中，这套组合的价值是：让不同 Agent 不只是在聊天，而是在同一个版本账本上协作。
一个典型的 ACE Agent 协作流程大概是这样：
这套分工不是抽象方法论，已经在几个真实项目里落地：
工具会变，模型会迭代，但“围绕任务事实、轻量分工、版本留痕”这套协作方式，是能在真实项目里持续生效的。
]]>很多人用 AI，是让一个 Agent 从头做到尾：自己分析、自己写代码、自己测试、自己宣布完成。这个方式在简单任务里没问题，但复杂任务里风险很高——它顺着自己的思路往下走，写完之后再让它自己检查，往往检查不出真正的问题。
它可能误判环境、重复改动、遗漏关键步骤，把没有验证的结果说成已经完成，甚至把错误包装得很像正确答案。这不是某个模型的问题，而是单 Agent 工作模式天然存在的问题。真实工程里，一个人写完代码还需要别人 code review，一个方案做完还需要别人质疑，一个系统上线前还需要测试验证。AI Agent 也是一样。如果一个 Agent 从头到尾自己做、自己验、自己宣布完成，复杂任务里的风险就会被隐藏起来。
提示词当然重要，但它解决不了所有问题。
复杂任务的难点不是“这句话怎么问得更好”，而是：任务目标是否明确、上下文是否稳定、文件版本是否清楚、改动范围是否受控、环境是否可信、结果是否验证、经验是否沉淀、下次能不能复用。这些问题，不是一个万能提示词能解决的。
比如让 AI 帮你改代码。如果它不知道当前项目目录、不知道正式入口、不知道依赖版本、不知道哪些文件不能乱改、不知道完成后该跑什么验证，那么提示词写得再漂亮，也可能出问题。再比如做一个内容项目，如果 AI 不知道这篇内容属于哪个项目、面向谁、后续放在哪里、和其他文章是什么关系，它可能写出一篇看起来不错但无法沉淀的文章。
复杂任务需要的不只是提示词，而是工作流——更准确地说，是一套轻量的 AI 工程协作方法。
AI 降低了太多事情的启动成本：不会写代码也能让 AI 帮你写，不会设计页面也能让它给方案，不会整理资料也能让它归纳，不会做 PPT 也能让它生成结构和视觉方向。这当然是巨大的变化。
但当所有事情都变得“好像可以做”之后，人很容易同时开太多坑——今天想做个人站，明天想做 AI 工具评测，后天想做自动化软件，再过两天又想研究视频工作流、知识库、开源项目、Agent 协作。能力被放大的同时，混乱也被放大。如果原来的工作方式是混乱的，AI 很可能会把这种混乱一起放大：聊天记录很多、文档很多、文件夹很多、半成品很多，但真正稳定完成的东西不多。AI 不是天然让人有序，它只是放大能力。
而且现在“复杂项目”不再是团队或公司专属。一个普通人做个个人站，会涉及内容结构、首页设计、项目页组织、文章迁移、GitHub 管理、部署和持续更新；做个 AI PPT 工作流，会涉及主题定位、受众判断、内容战略、视觉系统、导出测试和动效验收。这些事虽然都是个人项目，复杂度已经接近小型工程。AI 给了普通人做复杂项目的能力，也就自然带来了对方法论的需求。
ACE（Agent Collaboration Engineering）不是一个软件，也不是固定框架。它不是 Codex，不是 Claude Code，不是 WorkBuddy，也不是某个自动化平台。它更像一套工作方式：用 AI 做复杂项目时，怎么拆任务、怎么分角色、怎么让不同 Agent 协作、怎么记录工程事实、怎么控制风险、怎么做验收、怎么把有效经验沉淀下来。它解决的是 AI 参与真实项目时的组织问题。
它的核心思路是：不同 Agent 应该有不同角色，角色是动态的，任务事实是稳定的。
有的 Agent 负责架构，有的负责施工，有的负责审查，有的负责测试，有的负责总结沉淀。ACE 不把某个模型固定绑定到某个角色——这和“一个 Agent 从头做到尾”是根本区别。单个 AI 工具再强，如果没有组织方式，也很容易在复杂任务里跑偏。
在 AI 工程协作里，事实层尤其重要。当前项目目录是什么、正式入口是什么、用哪个运行时、哪些文件被改过、哪些验证已经跑过——这些都不能只靠聊天记录。ACE 重视两类事实：
不是所有任务都需要复杂流程。有些任务直接完成就行，不应该为了工程化而工程化。ACE 根据任务复杂度和风险决定处理方式：简单任务走轻量路径；中等任务拆分步骤；高风险任务先做蓝图、再施工、再验收；多 Agent 任务则明确角色、边界和交接方式。背后的原则很简单：流程为任务服务，不为了流程而流程。
验收同样如此。很多 AI 工程任务失败，不是因为没有做，而是因为没有真正验收；但另一个极端也很常见——为了显得严谨，每次都搞一套巨大验收，最后流程本身变成负担。ACE 采用最少充分验收：只验证本次改动直接影响的关键链路。小范围文案或样式改动不做全量回归；改配置就验证配置是否被正确读取；改入口就验证正式入口能不能跑通；改生产链路才需要更完整的回归和证据包。最少充分验收不是偷懒，而是把验证做到刚好够用。
说到工程方法，很多人会想到很重的流程：需求评审、架构设计、开发规范、测试报告、项目管理系统、多人协作平台。这些对大团队可能有必要，但对普通人太重了。普通人真正需要的不是复杂系统，而是轻量方法：这个任务要不要拆、哪些先做哪些先不做、AI 这次只负责什么、哪些文件可以改哪些不能碰、当前可信环境是什么、做完后最低限度验证什么、这次经验有没有必要沉淀。
这能避开两种极端。一种是完全无流程：想到什么做什么，AI 改到哪里算哪里，越做越乱。另一种是过度工程化：还没开始做事就先搭系统、写规范、建模板、做流程，最后真正产出反而很少。我更认可中间路线：先做事，后沉淀。轻量优先，复用优先。流程只服务于真实推进。 这也是 ACE 的核心精神。
Skill 沉淀遵循同样原则：只有真正可复用、高风险、反复失败、能提高效率的能力，才值得沉淀成 Skill。过度文档化会把知识库变成负担——整理系统的时间变多，真正做事的时间变少。先做事，后沉淀。
ACE 目前不是成熟产品，也不是万能框架。它更准确的状态是：一套正在真实项目中持续进化的个人 AI 工程协作方法论。它不追求完整而完整，而是越来越明确地——先做事，后沉淀，轻量优先，复用优先。
]]>本文正文待补（v0.2）：结构已就位，待有真实筛选经验后补齐，不预先编造。
AI 工具和开源项目更新很快。GitHub、B站、Twitter / X、YouTube、Product Hunt、Reddit 上经常能看到各种看起来很有价值的项目。但实际问题是：
AI Tool Reviews 的价值不在于“介绍很多工具”，而在于建立一套可复用的判断方式：一个工具是否值得进入我的真实工作流。
当前重点关注几类：
AI Tool Reviews 用 ACE 的工作流视角，重点看这几个问题：
AI Tool Reviews 不是孤立的工具收藏夹。它用 ACE 的工作流视角评估工具：这个工具能否降低复杂任务成本，能否进入 Agent 协作链路，能否被版本事实层和最少充分验收约束，能否在真实项目中反复复用。评测发现工具，项目验证工具，复盘再反哺评测模板–这是它和 ACE、TemuCanvas、AI PPT Workflow 之间的关系。
它仍处在 Building 阶段，当前重点是建立评测对象池、统一评测维度和轻量模板。第一阶段更重要的是少量真实评测、清晰结论和可复用判断框架，而不是把自己包装成权威榜单。
]]>Anchor AI Lab 有两个独立站点，各管一摊：
| 主站（Anchor AI Lab） | Blog | |
|---|---|---|
| 职能 | 产品展示 / 入口 / 品牌 | 长内容 / 方法论 / 复盘 |
| 更新节奏 | 随产品版本 | 持续、较高频 |
| 技术栈 | 独立 | Hexo + Butterfly（静态） |
| 关系 | 引用 Blog 内容作为背书 | 反哺主站的产品决策与案例 |
主站负责“我是谁、做什么、有什么项目”–产品展示、入口和品牌，随产品版本更新，节奏较慢但每次更新较重。Blog 负责“我怎么想、怎么做、复盘了什么”–长内容、方法论和复盘，持续更新、频率较高，是内容输出和经验沉淀的主阵地。
两者刻意解耦：Blog 不依赖主站的接口或数据，可以独立部署、独立演进。Blog 不会因为主站改版而受影响，主站也不会因为 Blog 频繁更新而跟着变动。
技术上各跑各的：主站是独立项目，Blog 是 Hexo + Butterfly，各自独立仓库、独立部署。内容上，Blog 文章可以在主站被引用作为方法论背书，但不强耦合；反过来，Blog 里的复盘和案例会反哺主站的产品决策。
一条内容放哪边，判断标准是它的性质：
比如 ACE 方法论、Agent 协作分工、AI PPT Workflow 流程、工具评测框架，这些是长内容和方法论，放 Blog；而“Anchor AI Lab 有哪些项目、定位是什么”放主站。主站的项目页可以链接到 Blog 的深度文章，把 Blog 作为背书和展开。
简单说：主站是“门面”，Blog 是“工坊”。门面展示成果，工坊沉淀方法。
]]>v0.1 的目标是搭一个最小可维护的静态博客壳，跑通内容生产流程，而不是追求功能完整。技术选型是 Hexo 8 + Butterfly 5。
内容原则是可复现 > 可读性 > 时效性–优先写能被未来自己重读、仍成立的东西。这条原则决定了 Blog 的内容主线：AI 工具评测、Agent 协作工程、AI 内容工作流、知识系统、构建日志。
source/css/theme.css 里的 --theme-color，全站按钮/链接/分隔线/滚动条变色。明确不做，避免过早复杂化：
v0.1 是基线版本：壳和流程就位，内容是占位结构、待补。后续版本在这个壳上迭代–补正文、部署上线、接评论与统计等。每个版本先更新 BLOG_PLAN_V0.1.md 的“v0.x 做什么 / 不做什么”再动手，保证范围清楚、不过早复杂化。