一个人的网站，能不能从开发到运营都由 AI 协助？

我最近一直在思考一个问题：

如果一个人的网站不只是展示页面，还承担内容生产、开发记录和日常运营，它是否仍然需要不断扩建传统后台？

过去的答案通常是肯定的。需要管理文章，就开发文章后台；需要管理组件，就增加组件后台；需要检查数据，就再做一套统计页面。每出现一种需求，就新增一个页面、一套表单和相应的权限逻辑。

但个人网站有一个特殊之处：它的使用者可能只有站长自己，需求却会随着网站成长不断变化。

今天我需要找出缺少摘要的文章，明天想判断一个选题是否已经写过，后天又希望根据文章内容生成一种新的展示组件。如果每个需求都先固化成后台功能，大量开发时间就会消耗在暂时只有自己使用的 CRUD 页面上。

与此同时，我日常使用的 ChatGPT、Codex 等成熟大模型工具，已经能够理解自然语言、分析内容、修改代码并调用外部工具。

相比继续扩建一个功能越来越多的后台，我更想尝试另一条路径：

把网站的数据、业务规则和受控操作提供给大模型。我负责说明目标，大模型负责理解任务并调用合适的工具，最终结果仍由我检查和确认。

GrowthTrace 就是在这个过程中出现的。

它不是一个新的大模型，也不是把 ChatGPT 复制进我的网站。它是一层连接：一端把网站真实的数据和操作能力提供给成熟大模型，另一面通过权限、流程和版本规则限制大模型能够做什么。

我想验证的问题也因此变得具体：

一个人能否借助现有的大模型工具，把网站开发、内容生产和日常运营连接成一条可持续推进的工作流？

为什么我不想继续扩建传统后台？

传统后台并没有失去价值。

当操作流程固定、使用人数较多，或者权限必须高度标准化时，可视化后台仍然清晰、稳定，也便于培训和交接。

但个人网站中的许多管理任务并不固定，也不值得专门开发页面。例如：

• 找出缺少关键词、摘要或描述的文章；
• 判断一个选题是否已经写过；
• 把一次讨论整理成文章草稿；
• 检查文章适合归入哪个写作项目；
• 根据文章内容挑选展示组件；
• 发现站内重复、断裂或长期没有更新的内容；
• 临时组合几个条件，检查当前网站状态。

这些任务往往同时包含查询、理解和判断。

传统后台可以把字段展示出来，却仍然需要我逐项查看；而大模型擅长把零散信息放进同一个任务上下文，理解我真正想完成的目标。

因此，我缺少的并不只是更多页面和表单，而是一层能够让大模型安全理解网站的接口。

这并不意味着删除所有后台。固定、高频、要求明确视觉反馈的操作仍然适合保留界面。AI 更适合承接那些变化快、频率低、需要组合查询和语义判断的任务。

对个人网站来说，两者可以并存：

• 传统界面负责稳定而高频的操作；
• 大模型负责理解临时目标和组织复杂任务；
• MCP 负责提供真实数据与受控工具；
• 用户负责审核结果和承担最终决策。

AI 能力从哪里来？

GrowthTrace 本身不提供语言理解、内容生成或代码推理能力。

这些能力来自我日常使用的成熟大模型工具，目前主要是 ChatGPT 和 Codex。

GrowthTrace 负责的是把网站连接到它们。

没有这层连接时，ChatGPT 可以帮助我讨论选题、整理结构或者生成文章，但它只能使用当前对话中出现的信息。它并不知道网站里已经有哪些文章，也不知道：

• 哪些文章已经公开；
• 哪些草稿尚未完成；
• 哪些文章缺少必要的内容元数据；
• 网站里有哪些写作项目；
• 哪些模板和组件可以复用；
• 哪些操作能够直接执行；
• 哪些操作必须等待人工确认。

为了让大模型回答这些问题，我需要先查询网站，再把结果复制到对话中。网站状态变化以后，旧对话里的信息也会逐渐失效。

GrowthTrace 通过 MCP 提供网站当前的数据和受控操作。大模型不再只依赖我手动复制的上下文，而是可以在任务需要时读取真实状态。

整体分工可以理解为：

这套结构的重点不是让某个大模型掌握全部权限，而是让不同部分各自承担清晰职责。

通用的理解和推理能力交给成熟大模型；网站特有的数据结构、业务规则和工具由我自己维护；最终决定仍然由人完成。

对于个人开发者来说，这比自己训练或封装一个新的 AI 助手更现实。我不需要重复建设通用能力，只需要开发与自己网站强相关的上下文和操作入口。

插件也参与自己的开发过程

我最初把 MCP 理解成插件开发完成后的使用接口：先把所有工具开发好，再交给 ChatGPT 调用。

实际开发以后，这个顺序发生了变化。

GrowthTrace 在开发阶段就开始被大模型调用。大模型不只是它未来的使用者，也参与工具契约、返回结构和权限边界的验证。

例如，我增加文章管理工具以后，可以让大模型实际读取文章库存、检查元数据、创建草稿，再根据真实返回判断：

• 字段名称是否足够清楚；
• 工具说明是否容易产生误解；
• 返回结果能否支持下一步操作；
• 权限边界是否符合预期；
• 工具返回成功是否真的代表目标完成。

开发过程因此形成了一条循环：

1. 我提出网站管理需求；
2. ChatGPT 或 Codex 帮助梳理数据结构、工具契约和权限；
3. 我和 Codex 完成对应代码；
4. 大模型调用刚开发的 MCP 工具；
5. 根据网站真实反馈发现问题；
6. 修改后重新调用和验证；
7. 稳定能力继续用于网站运营。

只阅读代码时，大模型主要根据静态上下文推测功能是否成立。能够调用插件以后，它还可以接触系统的真实反馈：网站现在拥有什么数据、调用有没有成功、结果是否满足后续任务。

于是形成了一个持续循环：

大模型帮助开发插件，插件把网站的真实状态提供给大模型，大模型再利用真实结果继续改进插件。

但工具调用成功并不等于任务已经完成。

创建文章接口返回成功，只能证明数据已经写入；它不能证明文章质量合格，也不能证明公开页面展示正确。组件编译通过，同样不能证明视觉和交互符合预期。

因此，预览、审核、版本记录、回读确认和人工批准仍然不可缺少。

这和直接使用 Codex 有什么不同？

Codex 非常适合处理开发任务。

当问题位于代码仓库中，我可以让它读取项目结构、修改代码、运行测试并检查构建结果。开发 GrowthTrace 本身时，Codex 是重要协作者。

但网站运营并不完全等同于代码开发。

文章是否公开、属于哪个写作项目、缺少哪些元数据，通常属于网站运行中的业务数据，而不是代码仓库里的文件。

如果每次运营都让 Codex 进入项目、连接数据库或临时调用内部接口，会产生几个问题：

• 每次都需要理解开发环境和项目结构；
• 不同部署环境的连接方式可能不同；
• 业务操作容易和底层代码修改混在一起；
• 手机端难以复用完整开发环境；
• 数据表发生变化后，原有操作方式可能失效；
• 直接访问底层数据很难表达清晰的业务边界。

GrowthTrace 将这些能力封装成稳定的业务工具。

Codex 不需要知道文章存在哪张数据库表，也不需要为了修改摘要而直接操作数据库。它只需要调用“读取文章”“更新文章”或“检查内容健康状况”等明确工具。

两者不是互相替代，而是分工不同：

Codex 更适合修改系统本身；GrowthTrace 更适合让大模型在系统规定的边界内使用和管理系统。

开发插件时可以使用 Codex；插件进入运营阶段以后，ChatGPT 和 Codex 都可以根据场景调用它。

这和直接使用通用 AI 工作台有什么不同？

即使不开发插件，我也可以打开 ChatGPT，把文章和网站数据复制进去，再让它分析。

这种方式适合一次性的临时任务，却很难形成稳定的运营流程。

不必在不同设备和对话之间反复搬运上下文

通用 AI 工作台通常只知道当前对话中提供的信息。

如果我在电脑上复制了一份文章列表，到了手机上重新开启对话，就可能需要重新整理。网站内容变化以后，旧对话中的状态也会过期。

接入 GrowthTrace 后，电脑和手机上的大模型可以通过相同工具查询网站当前状态。

真正被复用的不是某一段旧对话，而是网站持续提供的数据接口。

能够按需读取网站的真实状态

直接使用 AI 工作台时，我需要先从后台、数据库或代码中找到数据，再手动复制给大模型。

通过 MCP，大模型可以根据任务查询文章库存、文章正文、内容健康状况、写作项目、可用组件以及组件版本。

这可以减少手动整理，也降低使用过期数据作出判断的概率。

当然，能访问网站不代表可以读取所有数据。每个工具仍然需要控制返回范围，敏感数据也不应该因为接入大模型而默认开放。

能够表达网站特有的数据结构

“写作项目”“组件版本”“文章展示内容”和“内容健康状况”不是所有网站通用的概念，而是我的网站逐步形成的业务结构。

GrowthTrace 可以把这些概念转换成大模型能够理解和操作的明确对象。

工具返回的不只是数据库记录，还包含业务层定义的状态和边界。例如：

• 保存正文和公开文章是两个动作；
• 组件预览通过和正式保存版本是两个状态；
• 工具执行成功和最终效果验收是两个阶段。

明确的数据结构可以减少大模型对业务含义的猜测。

可以把权限按动作拆分

把数据库权限直接交给 AI，或者让它使用权限过大的通用接口，很难控制影响范围。

GrowthTrace 可以把读取文章、创建草稿、更新正文、公开文章和保存组件版本拆成不同工具，并设置不同的前置条件。

大模型获得的不是笼统的“网站管理权限”，而是一组边界明确的操作能力。

读取和分析可以保持低摩擦；覆盖、公开和保存正式版本等高风险操作，则要求用户明确确认。

工作流程能够重复使用

直接使用 AI 工作台时，一套可靠流程经常存在于越来越长的提示词中。更换会话、模型或设备后，规则可能需要重新说明。

插件可以通过 Skill 和工具契约保留稳定流程，例如：

• 先读取真实状态，再提出修改；
• 先搜索已有内容，再决定是否创建；
• 生成组件后先建立预览；
• 用户批准后才能保存正式版本；
• 公开内容前必须获得明确确认；
• 工具返回成功后继续回读最终结果。

这样，流程不会完全依赖我每次都记得写出全部约束。

为什么手机也能参与网站运营？

手机能够参与运营，并不是因为我又开发了一套移动端后台。

真正的原因是 ChatGPT 本身可以在手机上使用，而 GrowthTrace 可以把网站能力提供给 ChatGPT。

当客户端支持相应插件和工具调用时，我可以通过手机处理适合移动场景的任务：

• 记录临时选题和用户需求；
• 查询是否存在相似文章；
• 查看尚未完成的草稿；
• 补充提纲和素材；
• 审阅准备发布的内容；
• 检查文章是否缺少摘要或关键词；
• 把一段讨论整理成草稿。

手机是大模型的另一个使用入口，而不是另一套网站运营系统。

电脑端更适合代码开发、组件预览、文件处理和页面检查；手机端更适合记录、查询、整理和审阅。正式发布、组件保存等高风险操作仍然需要完整预览、明确确认和版本记录。

手机端能否调用全部能力，也取决于客户端当时对插件和工具调用的实际支持。这是一条仍需继续验证的工作链路，而不是所有设备和账号已经默认拥有的能力。

AI 能协助到哪里？

这套方案的目标不是让 AI 取代站长，也不是让网站无人监管地自动运行。

ChatGPT 可以理解数据、生成内容、整理候选方案和调用明确工具；Codex 可以修改代码、运行测试和完善系统；GrowthTrace 负责提供网站真实状态和受控能力。

但以下责任仍然属于站长：

• 网站定位和长期方向；
• 什么内容值得公开；
• 哪些风险可以接受；
• 生成结果是否符合真实需求；
• 视觉和交互是否达到预期；
• 是否执行不可逆或影响用户的操作。

因此，我现在得到的结论不是“网站可以完全由 AI 运营”，而是：

一个人可以让 AI 贯穿网站开发与运营，但前提是把真实上下文、稳定工具、权限边界和人工验收一起纳入系统。

对个人网站来说，这比继续堆叠后台页面更值得尝试。

我不需要为每一个临时需求建立固定界面，也不需要把数据库直接暴露给大模型。我需要的是一套能够逐步积累的网站能力：让成熟大模型读懂真实状态，在明确边界内完成操作，再把关键判断和最终发布留给自己。

这也是我开发 GrowthTrace 过程中最重要的一次认识。