一个人的副业网站，能不能从开发到运营都由 AI 协助？
我最近一直在思考一个问题：
如果个人网站不仅用于展示内容，还要逐渐承担内容生产、副业试验和用户反馈收集，一个人应该怎样维护它？
传统答案是继续开发后台：文章后台、组件后台、数据后台、运营后台。每增加一种需求，就增加一个页面、一套表单和相应的权限逻辑。
但我对继续开发传统后台没有太大兴趣。
个人网站的需求变化很快，使用者可能只有站长自己。今天需要整理文章，明天想检查内容元数据，后天又希望生成一种新的文章展示组件。如果每个需求都先开发一个固定界面，大量时间就会被消耗在暂时只有自己使用的 CRUD 页面上。
与此同时，我日常使用的 ChatGPT、Codex 等大模型工具已经能够理解需求、生成内容、分析代码和调用外部工具。
相比重新开发一个功能越来越多的后台，我更希望做另一件事：
把网站的数据、能力和业务规则提供给大模型，让我可以直接描述目标，再由大模型调用受控工具完成相应工作。
GrowthTrace 就是在这个过程中出现的。
它目前还不是一个已经得到市场验证的副业产品，而是我为自己的网站开发的一套 AI 协作接口。我想用它验证：
一个人能不能借助成熟的大模型工具，把网站开发、内容生产和日常运营连接成一条可以持续推进的工作流？
AI 能力从哪里来？
首先需要明确，GrowthTrace 本身不是一个大模型，也不负责提供语言理解、内容生成和代码推理能力。
这些 AI 能力来自我日常使用的成熟大模型工具。目前主要是 ChatGPT 和 Codex。
GrowthTrace 负责的是另一部分：把我的网站连接到这些大模型工具。
没有插件时，ChatGPT 可以帮我讨论选题、生成文章或者提出运营建议，但它只能使用我在当前对话中提供的信息。
它不知道网站里已经有哪些文章，也不知道：
- 哪些文章已经公开；
- 哪些草稿还没有完成；
- 哪些文章缺少摘要、描述或关键词；
- 网站有哪些写作项目；
- 哪些模板和组件可以复用；
- 哪些操作可以直接执行；
- 哪些操作必须等待人工确认。
为了让 ChatGPT 回答这些问题，我只能手动查询网站，再把结果复制进对话。等网站状态发生变化以后，之前复制的内容又可能过期。
GrowthTrace 的作用，就是通过 MCP 把网站当前的数据和受控操作提供给大模型。
整体分工可以理解为：
| 组成部分 | 主要职责 |
|---|---|
| ChatGPT | 理解自然语言、分析问题、生成内容、规划操作 |
| Codex | 阅读和修改代码、运行测试、处理开发环境中的任务 |
| GrowthTrace 插件 | 描述可用工具、调用规则和工作流程 |
| MCP 服务 | 返回网站真实数据，执行经过约束的网站操作 |
| 网站系统 | 保存文章、项目、组件、模板和版本 |
| 用户 | 决定方向、审核结果、确认高风险操作 |
因此，我不是在为网站重新开发一个 AI，也不是把 ChatGPT 复制到自己的网站里。
我做的是：
使用成熟大模型已有的理解和生成能力，再通过 MCP 给它补充我的网站数据、业务规则和操作入口。
对于个人开发者来说，这种分工更加现实。通用推理能力由成熟的大模型产品提供，我只需要开发与自己网站强相关、具有差异化的数据和工具。
为什么我不想继续扩建传统后台？
传统后台并非没有价值。
当操作流程固定、使用人数较多或者权限需要高度标准化时，可视化后台仍然是清晰而稳定的选择。
但个人网站的情况不同。
很多操作并不值得专门开发一个页面。例如：
- 找出缺少关键词的文章；
- 判断一个选题是否已经写过；
- 把一次讨论整理成草稿；
- 检查某篇文章适合归入哪个写作项目；
- 根据文章内容选择展示组件；
- 发现站内重复或断裂的内容。
这些任务往往同时涉及查询、理解和判断。传统后台可以展示数据，却仍然需要我自己逐项查看。
大模型擅长的正是把这些零散信息放到同一个任务上下文里处理。
所以我真正缺少的不是更多表单，而是一个能够让大模型安全理解网站的接口层。
插件并不是开发完成后才交给 AI
我最初把 MCP 理解成插件完成后的使用接口：先由我把工具开发完，再让 ChatGPT 调用。
实际开发以后，这个顺序发生了变化。
GrowthTrace 在开发阶段就已经开始被大模型调用。大模型不只是插件未来的使用者，也在参与插件自身的设计、验证和改进。
例如，我为文章管理增加工具后，大模型可以实际读取文章库存、检查缺失的内容元数据、创建草稿，再根据工具的真实返回结果判断：
- 字段设计是否足够清楚；
- 工具说明是否容易误解；
- 返回结果是否包含完成下一步所需的信息；
- 权限边界是否正确；
- 工具成功是否真的意味着任务完成。
整个开发过程因此变成：
- 我提出一个网站管理需求；
- ChatGPT 或 Codex 帮助梳理数据结构、工具契约和权限边界；
- 我与 Codex 完成相应代码；
- 大模型调用刚刚开发的 MCP 工具；
- 根据真实结果发现问题；
- 修改以后重新调用和验证；
- 将有效的能力继续用于网站运营。
这与普通的 AI 辅助编程有所不同。
只看代码时，大模型主要根据静态上下文推测功能是否成立。能够调用插件后，它还可以获得系统的真实反馈：网站当前有什么数据、调用是否成功、结果是否符合实际需求。
于是形成了一个循环：
大模型帮助开发插件，插件把网站的真实状态提供给大模型，大模型再利用这些结果继续改进插件。
不过，“工具调用成功”不能直接等同于“目标已经完成”。
创建文章接口返回成功，只能说明数据已经写入；它不能证明文章质量合格，也不能证明公开页面已经正确展示。组件编译成功，同样不能证明视觉和交互已经符合预期。
因此，插件仍然需要预览、审核、版本记录和人工确认。
这和直接使用 Codex 有什么不同？
Codex 非常适合处理开发任务。
当问题位于代码仓库中，我可以让它读取项目结构、修改代码、运行测试并检查构建结果。开发 GrowthTrace 本身时，Codex 是重要的协作者。
但网站运营并不完全等同于代码开发。
一篇文章是否公开、属于哪个写作项目、缺少哪些元数据，通常属于网站运行中的业务数据，而不是代码仓库中的文件。
如果每次都让 Codex 直接进入项目、连接数据库或者临时调用内部接口，会出现几个问题：
- 它需要获得开发环境和项目结构；
- 不同部署环境的连接方式可能不同；
- 业务操作容易和底层代码修改混在一起；
- 手机端难以复用完整的开发环境；
- 每次操作都需要重新理解网站的数据结构。
GrowthTrace 把这些网站能力封装成稳定的业务工具。
Codex 不需要知道文章存在哪张数据库表，也不需要为了修改摘要而直接操作数据库。它只需要调用“读取文章”“更新草稿”或者“检查内容健康状况”等明确工具。
所以两者不是互相替代，而是分工不同：
Codex 更适合修改系统本身，GrowthTrace 更适合让大模型在系统提供的边界内使用和管理系统。
开发插件时，我可以使用 Codex；插件投入运营以后，ChatGPT 和 Codex 都可以根据场景调用它。
这和直接操作通用 AI 工作台有什么不同？
即使不开发插件，我也可以打开 ChatGPT，把文章和网站数据复制进去，再让它分析。
这种方式适合临时任务，却很难形成稳定的运营流程。
第一，多端使用时不必反复搬运上下文
通用 AI 工作台通常只知道当前对话中出现的信息。
如果我在电脑上把文章列表复制给 ChatGPT，到了手机上重新开启一次对话，就可能需要再次整理这些数据。网站内容发生变化以后，旧对话里的信息也会逐渐失效。
接入 GrowthTrace 后，电脑和手机上的 ChatGPT 可以通过相同工具查询网站当前状态。
真正被复用的不是一段旧对话，而是网站提供的实时数据接口。
第二，可以更快捷地接入网站真实数据
直接使用 AI 工作台时，我需要先从后台、数据库或者代码中找到数据，再手动复制给大模型。
通过 MCP，大模型可以按需查询：
- 文章库存；
- 文章详细内容；
- 内容健康状况；
- 写作项目；
- 可用组件；
- 组件能力和版本状态。
这样既减少了手动整理，也降低了使用过期数据作出判断的概率。
不过，工具返回的数据仍然需要控制范围。大模型不应该因为能够访问网站，就默认读取所有数据或获得所有写入权限。
第三，可以表达高度定制化的数据结构
通用 AI 工作台并不知道“写作项目”“组件版本”“文章展示内容”和“内容健康状况”在我的网站中分别意味着什么。
这些不是所有网站通用的字段，而是我的网站逐步形成的业务结构。
GrowthTrace 可以把这些概念转化为大模型能够读取和操作的明确对象。工具返回的不只是一段数据库记录，而是经过业务层解释的数据。
例如，“文章公开”与“正文保存”是两个不同动作；“组件预览通过”与“组件版本正式保存”也不是同一个状态。
这种定制化结构能够减少大模型对业务含义的猜测。
第四，权限和风险可以按动作拆分
把数据库权限直接交给 AI，或者让它操作一个权限过大的通用接口，很难控制影响范围。
GrowthTrace 可以把读取文章、创建草稿、更新正文、公开文章和保存组件版本拆成不同工具，并分别设置前置条件。
这样，大模型获得的不是笼统的“网站管理权限”，而是一组边界明确的操作能力。
高风险操作可以要求人工确认，读取操作则可以保持低摩擦。
第五，工作流程可以重复，而不只依赖一次提示词
直接使用 AI 工作台时，一套可靠流程往往存在于一段越来越长的提示词中。更换会话、模型或设备后，这些规则可能需要重新说明。
插件可以通过 Skill 和工具契约保留稳定流程，例如：
- 先读取真实状态，再提出修改；
- 先搜索现有组件，再决定是否生成；
- 生成组件后先创建预览；
- 用户批准以后才能保存版本；
- 公开内容前必须明确确认；
- 工具返回成功后继续检查最终结果。
这使工作流不完全依赖我每次都记得写出所有约束。
为什么手机也能辅助运营？
手机能够参与运营，并不是因为我又开发了一套移动端网站后台。
真正的原因是：ChatGPT 本身可以在手机上使用，而 GrowthTrace 可以把网站能力提供给 ChatGPT。
当手机端 ChatGPT 能够调用这套插件时，我就可以通过对话处理适合移动场景的任务，例如：
- 记录临时出现的选题；
- 查询网站中是否已经存在类似文章；
- 查看哪些草稿还没有完成；
- 补充文章提纲和素材；
- 审阅准备发布的内容；
- 检查文章是否缺少摘要或关键词；
- 把一段讨论整理成文章草稿；
- 记录潜在用户提出的新需求。
这里的手机可以理解为 ChatGPT 的另一个使用入口。
电脑端和手机端使用的是同一类大模型能力，也可以接入同一套网站工具。它们不需要分别对应两套网站运营系统。
不过，两种设备适合承担的任务并不完全相同：
| 手机端适合处理 | 电脑端适合处理 |
|---|---|
| 灵感和需求记录 | 插件与网站代码开发 |
| 内容查询 | 组件生成与完整预览 |
| 草稿生成和整理 | 文件和图片处理 |
| 文章审阅 | 页面与交互检查 |
| 运营状态查询 | 正式发布与高风险确认 |
这不是由设备本身决定权限，而是根据操作风险和验证条件划分工作。
例如，手机端可以生成草稿、提出修改建议，但不应该在没有完整预览的情况下自动覆盖或公开线上内容。正式发布、组件保存等操作仍应保留明确确认，并记录版本和执行结果。
手机端能否调用全部插件能力，也取决于 ChatGPT 当前客户端对插件与工具调用的实际支持。因此，我描述的是自己希望建立和继续验证的使用链路，而不是所有设备和账号都已经具备的通用能力。
这和副业有什么关系？
如果只是为了管理少量文章，开发插件很容易变成另一种形式的过度建设。
它是否值得继续，取决于能否逐步解决更普遍的问题。
我目前设想的路径是：
- 先把 GrowthTrace 用于自己的网站；
- 记录开发和运营中反复出现的问题；
- 判断哪些问题同样存在于其他个人网站；
- 把稳定能力提炼成模板、组件、脚本或 MCP 连接器；
- 通过文章和实际交流收集需求证据；
- 再决定是否提供接入服务或边界明确的轻量定制。
这条路径不意味着“做出一个插件就能形成副业”。
技术可行性、个人使用价值和商业价值是三个不同阶段。
插件首先要降低我自己的运营成本；其次要证明问题不只属于我；最后还要发现别人愿意付费解决的部分。缺少其中任何一步，都不能把它直接解释成一项成立的生意。
我现在更应该收集的是三类证据：
- 是否有人反复遇到相同的网站运营问题；
- 这些问题是否带来了明显的时间或维护成本；
- 用户更愿意自己配置工具，还是为接入和维护付费。
我接下来准备怎样验证？
我不会立刻把 GrowthTrace 做成一个庞大的通用后台。
接下来更适合完成几个小范围验证：
- 继续记录自己反复遇到的网站管理任务；
- 区分查询、生成建议、创建草稿和正式写入的权限；
- 验证手机端是否适合完成选题、查询、整理和审阅；
- 记录 ChatGPT 与 Codex 分别更适合处理哪些任务；
- 邀请少量个人站长描述他们最耗时的运营工作；
- 只为出现重复证据的问题开发可收费的最小能力。
如果最终只有我自己需要这套工作流，它仍然可以作为个人网站的内部基础设施。
如果其他个人开发者也面临相似问题，它才可能进一步变成可复用的连接器、模板或轻量服务。
我想验证的不是“AI 能不能代替站长”
我并不认为网站应该完全交给 AI 自主运营。
ChatGPT 可以帮助理解数据、生成内容、整理候选方案和调用明确工具；Codex 可以帮助修改代码、运行测试和完善系统；GrowthTrace 则负责把网站的真实状态和受控能力提供给它们。
但网站定位、风险接受、内容判断和最终发布仍然需要站长负责。
我真正想验证的是：
一个人能不能借助现有的大模型工具，把原本分散在开发环境、网站后台和临时笔记中的工作，连接成一条多端可用、数据可以随时读取、结果可以检查、关键操作仍由自己决定的流程。
如果你也在维护个人网站，我很想知道：
你最希望 ChatGPT 帮你完成哪一项工作——整理内容、生成页面、查询网站状态，还是把零散想法变成可以继续执行的运营任务？
如果存在一个可以让 ChatGPT 或 Codex 读取并管理网站内容的连接器，你更愿意自己配置，还是希望有人帮助你完成接入？