企业官网建设流程全解析

最近关于“资深终端用户是否还需要命令行”的讨论热度很高，Theo 在 t3.gg 上也分享过相关观察：越来越多的资深开发者，正在把原本亲手敲的命令行操作，交给 AI 编程助手去完成。这个现象不是个例，而是 AI 编程时代工作流迁移的一个缩影。

早几年的开发习惯是“能命令行绝不用鼠标”，grep、sed、awk、git、docker、ssh 一条龙。但最近两年，随着 Cursor、Cline、Claude Code 这类 AI 编程工具逐渐成熟，不少人的操作习惯正在发生结构性变化——从“敲命令指挥机器”变成“写需求描述指挥 AI”，再由 AI 去调用命令完成具体操作。

这篇文章不打算讨论“命令行会不会被淘汰”这种口水问题，而是想拆解三件事：

1. 为什么资深终端用户开始放弃亲手敲命令行？
2. AI 编程时代的新型工作流到底长什么样？
3. 如何把自己原来的命令行技能迁移到新工作流里？

文章会涉及上下文工程、需求描述、Plan-Execute 循环、MCP 等概念，并给出一套完整的实战案例，适合正在观望 AI 编程工具的开发者阅读。

1. 背景：为什么“命令行至上”正在被挑战

1.1 资深终端用户的经典工作方式

在图形界面普及之后，命令行仍然被开发者长期保留，原因是它有三个不可替代的优点：

• 精准：一条命令表达一个明确操作，不会有图形界面的多级菜单干扰。
• 可复用：命令可以写成脚本，一键执行，天然支持自动化。
• 高效：熟练之后，git checkout -b feature/user-points这样的操作比鼠标点十几次快得多。

经典命令行工作流通常是这样的：打开终端，通过grep定位代码，用sed或编辑器修改文件，运行pytest或npm test验证，最后用git提交。所有环节都在一个终端窗口里完成，信息密度很高。

1.2 一个正在发生的转变

过去，开发者把大量时间花在“如何执行”上：记住命令参数、拼装管道、调试脚本。现在，AI 编程工具把“如何执行”这一步接管了。

你只需要告诉 AI“给用户模块加一个积分查询接口”，它会自动帮你完成以下动作：

1. 扫描项目结构，理解现有代码。
2. 生成修改计划。
3. 自动调用命令行工具创建文件、运行测试。
4. 把结果整理后反馈给你审查。

这里有一个关键点：命令行并没有消失，git、pytest、npm 这些工具还在被调用，只是执行者从“人”变成了“AI Agent”。所以更准确的说法是：资深终端用户放弃的不是命令行本身，而是“亲手敲命令行”这个动作。

1.3 讨论边界

本文讨论的是“AI 编程时代的工作流”，不讨论具体某款商业工具的付费策略，也不做工具排名。文章中出现的工具名称只用于举例，你可以根据团队实际情况选择。

2. 核心概念：命令行、AI 编程与新工作流

2.1 终端与命令行的准确含义

先澄清两个容易混淆的概念：

• 终端（Terminal）：是一个字符界面程序，用来与 Shell 交互。
• 命令行（Command Line）：指通过输入文本命令来操作系统的方式。

在 AI 编程时代，这两个概念都延伸了。AI 编程助手内部往往自带一个“虚拟终端”，它可以在沙箱环境中执行命令，并把输出解析成结构化信息。所以 AI 编程工具不是抛弃了命令行，而是把命令行封装成了模型可调用的工具。

2.2 AI 编程工具到底做了什么

AI 编程工具的本质，是把“自然语言到代码”的转换过程产品化。它们通常包含三个层次：

早期的 AI 编程工具只是“高级自动补全”，现在的 Agent 类工具已经具备自主执行能力。这也是工作流发生变化的根本原因：当 AI 能替你把命令跑完，你自然不再需要自己敲命令。

2.3 “工作流”的两种含义

“工作流”这个词在最近的热搜中出现频率很高，但含义完全不同：

• 业务工作流：指 Flowable、Camunda、Dify、Coze、n8n 这类工作流引擎，解决的是业务流程编排问题。
• AI 编程工作流：指开发者与 AI 协作完成编码任务的过程编排，比如写需求、生成计划、执行修改、运行测试、人工审查。

本文讨论的是第二种。理解这个区别，可以避免在技术方案选型时把它们混为一谈。

2.4 新工作流的三个关键角色

一个完整的 AI 编程工作流，通常有三个角色：

1. 人（Human）：负责表达意图、审查结果、做最终决策。
2. AI Agent：负责理解需求、生成代码、调用工具、验证结果。
3. 工具链（Toolchain）：包括 Git、测试框架、Linter、MCP Server 等。

三个角色的关系可以概括为：人定义“做什么”，AI 决定“怎么做并执行”，工具链提供“可执行环境”。

3. 资深终端用户为什么“放弃”命令行

3.1 瓶颈从“如何做”变成“做什么”

过去的开发瓶颈是“知道某个命令怎么写”，现在的瓶颈变成了“能不能把需求描述清楚”。

举个例子，你想在项目里添加一个“用户积分查询”接口。传统方式下，你需要知道 FastAPI 的路由怎么写、ORM 怎么用、测试怎么组织；AI 方式下，你只需要把需求规则说清楚，AI 会生成对应的路由、service 和测试。

当 AI 能稳定处理“如何做”之后，终端用户花在记忆命令语法上的时间收益就明显下降了。你不再需要记住git revert和git reset的区别，只需要告诉 AI“回滚最近一次提交”。

3.2 上下文断层是终端的结构性问题

终端的核心痛点是上下文断层。

你在终端里执行grep -rn "TODO" src/，得到的结果只有匹配行，没有代码结构、没有函数调用关系、没有项目整体信息。要理解一段代码，你需要手动拼接多个命令的输出。

而 AI 编程助手在启动时会把整个项目的文件索引加载进上下文。当它看到“用户积分查询”这个需求时，它能同时理解：

• user.py里用户表的结构。
• points.py里积分表的关联关系。
• main.py里路由的注册方式。
• tests/里已有的测试风格。

这种全局上下文，是终端命令的离散输出无法比拟的。

3.3 多文件改动与跨模块重构的痛点

单个文件的修改，终端用户用 vim 或 sed 就能搞定。但跨模块重构时，比如“把用户查询逻辑从 routers 层移到 services 层”，终端用户需要手动打开多个文件，逐个调整 import、函数签名、调用关系。这个过程不仅慢，而且容易遗漏。

AI 编程工具在处理这类“多文件联动修改”时优势明显。它能一次性生成完整的修改方案，并按依赖顺序调整所有相关文件，最后通过运行测试来确认没有破坏其他模块。

3.4 会话沉淀：调试过程成为可复用资产

终端还有一个隐藏成本：调试过程无法沉淀。

你在终端里执行了一串命令解决了一个 bug，这串命令可能永远不会被记录下来。下次遇到同样的问题，你还要重新回忆排查步骤。

AI 编程助手的会话可以被保存、导出、甚至写成文档。比如你让 AI 排查“Redis 连接超时”问题，排查过程、最终结论、修改的代码都会留在会话记录里。这些记录本身就是可复用的团队知识库。

3.5 一个重要澄清：命令行没有被淘汰，只是执行者变了

需要强调的是，命令行仍然在每天被大量调用。AI 编程工具在执行任务时，内部会调用git diff、npm test、docker compose up等命令。

所以正确的理解是：命令行从“用户直接操作的对象”变成了“AI Agent 操作的对象”。资深终端用户依然需要理解命令行能做什么，理解命令的输出意味着什么，只是不再需要亲手输入每一条命令。

4. 新工作流的核心机制拆解

4.1 上下文工程：给 AI 提供项目地图

AI 编程工具虽然能索引代码，但它不知道你的项目约定。比如：

• 业务逻辑必须放在 services 层。
• 数据库访问必须走 repositories。
• 新增接口必须有测试。
• 某些目录是自动生成的，不要修改。

这些约定需要写在项目里，常见的文件名是CLAUDE.md、AGENTS.md、CONTEXT.md。AI 编程助手会自动读取这些文件作为上下文。

一个典型的上下文文件内容：

# 项目上下文（示例：points-service） ## 技术栈 - Python 3.11 + FastAPI - PostgreSQL 15 - Redis 7 ## 目录结构 - app/main.py：应用入口 - app/routers/：HTTP 路由，只做参数校验和响应封装 - app/services/：业务逻辑 - app/repositories/：数据访问层 - tests/：pytest 测试 ## 常用命令 - 启动服务：uvicorn app.main:app --reload - 运行测试：pytest tests/ -v - 数据库迁移：alembic upgrade head ## 编码规范 - 禁止在 routers 层写业务逻辑 - 数据库访问必须走 repositories - 新增接口必须有对应单元测试

这段内容能显著提升 AI 生成代码的质量。它相当于给 AI 画了一张项目地图，避免 AI 在错误的位置添加代码。

4.2 需求描述：AI 编程时代的“新命令”

如果说传统的命令行是你的“操作语言”，那么需求描述就是 AI 编程时代的“新命令语言”。

写需求描述不是简单地说“帮我加个积分接口”。高质量的需求描述应该包含：

• 功能描述。
• 业务规则和边界情况。
• 输入输出示例。
• 验收标准。

下面是一个可直接套用的需求描述模板：

# 需求：新增“查询用户积分”接口 ## 功能描述 提供 GET /users/{user_id}/points 接口，返回指定用户的当前积分。 ## 业务规则 1. 用户不存在时返回 404，错误码 USER_NOT_FOUND 2. 用户存在但从未有过积分记录时，返回 0 3. 积分必须为非负整数，异常值按 500 处理并记录日志 ## 输入输出示例 GET /users/1001/points 200 Response： {"user_id": 1001, "points": 120} ## 验收标准 - 覆盖：存在积分 / 无积分记录 / 用户不存在 三种情况 - 所有 pytest 测试通过 - 不得修改数据库表结构

好的需求描述能让 AI 一次生成接近正确的代码，减少来回纠错的 round-trip。这是 AI 编程时代最重要的“提示词技巧”。

4.3 Plan-Execute 循环

成熟的 AI 编程工作流不是让 AI 直接改代码，而是采用“Plan-Execute”两阶段模式：

1. Plan 阶段：AI 阅读上下文，分析需求，输出修改计划，列出涉及的文件和改动点，等待用户确认。
2. Execute 阶段：用户确认计划后，AI 才动手修改代码、运行测试、修复问题。

这种模式的好处是：把 AI 的“思考过程”暴露给用户，用户可以提前发现方案缺陷，避免 AI 在错误方向上越走越远。

Cursor 的 Plan Mode、Cline 的 Plan/Act 切换、Claude Code 的只读模式，本质上都是这个思路。

4.4 工具调用与 MCP

AI Agent 要真正执行任务，必须能调用外部工具。这里不得不提MCP（Model Context Protocol，模型上下文协议）。

MCP 是一个开放协议，它定义了 AI 应用与外部工具、数据源之间的标准通信方式。通过 MCP，AI 编程助手可以统一访问：

• 本地文件系统。
• Git 仓库。
• 数据库。
• 外部 API。
• 浏览器调试工具。

一个 MCP 配置的简化示例如下（不同客户端的配置格式有差异，请以官方文档为准）：

{ "mcpServers": { "project-postgres": { "command": "your-mcp-postgres-server", "args": ["--connection", "postgresql://localhost:5432/points_service"], "env": {} } } }

有了 MCP，AI 就能在你授权的前提下查询数据库、查看线上日志、执行 git 操作，而不只是“生成代码”。

4.5 质量闸门：测试与人工审查

AI 生成的代码不能直接进生产环境。新工作流必须设置质量闸门：

1. 自动测试：AI 修改完代码后，必须运行测试套件。
2. Lint 检查：用 ruff、eslint 等工具检查代码风格。
3. 人工 Review：开发者逐行检查 AI 生成的代码，重点关注边界情况、安全问题、业务逻辑是否符合预期。

这四步构成了一个完整的质量闭环。

5. 完整实战：用 AI 工作流给 FastAPI 项目新增接口

下面用一个完整案例演示新的 AI 编程工作流如何落地。案例场景是一个 FastAPI 项目 points-service，需要新增“查询用户积分”接口。

5.1 项目背景与准备

假设项目结构如下：

points-service/ ├── app/ │ ├── main.py │ ├── routers/ │ │ └── user.py │ ├── services/ │ │ └── user_service.py │ └── repositories/ │ └── user_repo.py ├── tests/ │ └── test_user.py └── CLAUDE.md

代码使用 FastAPI 编写，数据库用 PostgreSQL，测试用 pytest。

5.2 编写项目上下文文档

在项目根目录先创建CLAUDE.md（或者AGENTS.md，取决于你使用的 AI 工具），内容参考第 4.1 节的模板。这一步很关键，它的作用是让 AI 在开始工作前就了解项目约定。

5.3 编写需求描述文档

创建一个docs/requirements/points_query.md文件，写入第 4.2 节的需求描述模板。写清楚业务规则、输入输出示例、验收标准。

5.4 让 AI Agent 生成计划与代码

在 AI 编程助手中输入以下指令：

请阅读 CLAUDE.md 和 docs/requirements/points_query.md， 先输出实现计划，不要直接修改代码。 计划里需要列出：涉及的文件、路由设计、数据访问方式、测试用例。

AI 会输出类似下面的计划：

• 新增app/routers/points.py，注册/users/{user_id}/points路由。
• 在repositories层新增积分查询方法。
• 在tests/下新增test_points.py。

确认计划无误后，允许 AI 执行修改。它会自动创建文件、补充代码，然后运行测试。

AI 生成的接口代码核心部分类似：

# 文件路径：app/routers/points.py from fastapi import APIRouter, HTTPException from app.repositories.points import PointsRepository router = APIRouter(prefix="/users", tags=["points"]) @router.get("/{user_id}/points") def get_user_points(user_id: int): repo = PointsRepository() if not repo.user_exists(user_id): raise HTTPException(status_code=404, detail="USER_NOT_FOUND") points = repo.find_points_by_user_id(user_id) return {"user_id": user_id, "points": points if points is not None else 0}

注意，这里省略了依赖注入和数据库连接细节，实际项目中需要结合项目现有写法调整。

5.5 补充与运行测试

AI 生成的测试用例类似：

# 文件路径：tests/test_points.py from fastapi.testclient import TestClient from app.main import app client = TestClient(app) def test_get_points_when_user_has_points(): resp = client.get("/users/1001/points") assert resp.status_code == 200 assert resp.json()["points"] == 120 def test_get_points_when_user_not_exists(): resp = client.get("/users/99999/points") assert resp.status_code == 404 assert resp.json()["detail"] == "USER_NOT_FOUND"

在终端执行：

pytest tests/test_points.py -v

确认全部通过。

5.6 人工审查与提交清单

在合并代码前，人工审查重点关注：

• [ ] 路由是否注册到 main.py。
• [ ] 业务逻辑是否放在 services 层，而不是 routers 层。
• [ ] 数据库查询是否走了 repositories。
• [ ] 是否有 SQL 注入风险。
• [ ] 测试是否覆盖了全部边界情况。
• [ ] 错误码是否符合团队规范。

确认无误后，让 AI 执行 git 提交：

git add . git commit -m "feat: 新增查询用户积分接口"

这样一个完整的 AI 编程工作流就结束了。

6. 常见问题与排查思路

6.1 AI 新开会话就丢失上下文记忆

这是 AI 编程工具使用中最常见的痛点。每次新建会话，AI 都会忘记之前的讨论内容。

根本解法是：不要把重要信息只放在聊天记录里，要沉淀到项目文件中。一次会话的产出物，应该是一个需求文档、一个计划文档、一批代码改动，而不是一段聊天记录。

6.2 AI 生成的代码运行失败

遇到这类问题，不要把报错原样丢给 AI 就不管了。正确做法是：把完整的堆栈日志、相关文件内容、你预期得到的输出一起提供给 AI，它能更精准地定位问题。

6.3 权限失控与安全风险

AI Agent 能执行命令，意味着它也有破坏力。常见风险包括：

• AI 执行了DROP TABLE之类的危险 SQL。
• AI 读取了不该读取的敏感配置。
• AI 把私有密钥写入了代码仓库。

安全原则应该前置：AI 工具只应在开发沙箱或本地环境使用，不允许在生产环境直接执行命令；涉及数据库变更的 AI 操作，必须走迁移脚本并由人工复核。

6.4 工作流无法复现

可复现的关键是：配置版本化、依赖锁定、上下文文档入库。

6.5 Token 消耗失控

AI 编程工具按 token 计费，长项目、大仓库的 token 消耗可能很高。

实际经验是：使用好的上下文文档，能把 token 消耗降低 30% 到 50%，因为 AI 不需要反复向你确认需求。

7. 命令行还值得学吗：新旧工作流的融合

7.1 命令行仍然不可替代的场景

即使 AI 编程工具越来越强，命令行在以下场景仍然不可替代：

# 场景 1：服务器运维 ssh user@server "systemctl status nginx && tail -f /var/log/nginx/error.log" # 场景 2：文本处理与数据管道 cat access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20 # 场景 3：容器与编排 docker compose up -d && docker compose logs -f api

这些场景的特点是：操作对象是远程服务器、日志文件、容器环境，AI 工具无法直接访问，或者授权成本过高。此时命令行依然是最高效的方式。

7.2 推荐混合工作流

我的建议不是“放弃命令行”，而是把命令行与 AI 编程工作流结合：

1. 用命令行做基础设施操作：远程连接、日志查看、容器管理。
2. 用 AI 做代码生成与重构：需求理解、多文件修改、测试生成。
3. 用命令行做结果验证：跑测试、查 git diff、部署。

比如，让 AI 生成一个部署脚本，你在本地用shellcheck检查脚本，再在服务器上执行脚本。这就是典型的人机协作混合工作流。

7.3 新手学习路线的调整

如果你刚入门编程，我的建议是：

• 仍然要学命令行基础，但不要死记硬背所有参数。
• 学会cd、ls、cat、grep、git这些高频命令。
• 理解文件系统、环境变量、进程管理的基本概念。
• 把“如何提问 AI”当成一项核心技能来练习。

原因很简单：AI 编程时代，你不需要记得每一条命令的参数，但你必须理解命令的语义和输出，才能判断 AI 执行得对不对。

8. 最佳实践与工程建议

8.1 最小权限原则

无论使用哪一款 AI 编程工具，都要遵循最小权限原则：

• AI Agent 只在项目目录内运行，不要给它全局文件系统的写权限。
• 数据库操作使用只读账号，除非明确需要写数据。
• 不要在需求文档中写入生产环境的密钥、密码。
• 涉及生产环境的变更，一律走人工审批流程，不允许 AI 直接执行。

8.2 版本控制与回滚策略

AI 修改代码前，先确认当前工作区是干净的：

git status git diff

在关键节点创建提交点或分支，方便回滚。如果发现 AI 改坏了代码，可以立即恢复：

git checkout -- .

建议每次让 AI 完成一个独立功能后，立即提交一次，而不是攒到最后统一提交。这样既能隔离问题，也能看到每一步的改动内容。

8.3 测试驱动 AI 编程

让 AI 先写测试，再写实现代码，能显著提升质量。因为测试定义了“什么叫完成”，AI 后续的所有修改都必须通过测试验证。

推荐的组合是：

1. 需求文档中写清楚验收标准。
2. 让 AI 先写测试用例。
3. 确认测试覆盖了所有边界情况。
4. 让 AI 写实现代码并使测试通过。

8.4 成本控制

如果团队在评估 AI 编程工具的成本，可以从几个角度控制：

• 只在复杂度高的任务上使用 Agent 模式，简单补全用普通模式。
• 把项目上下文文档写好，减少无效对话轮次。
• 定期清理不必要的会话记录和缓存文件。
• 对 token 消耗设置预算提醒，避免单个任务失控。

8.5 人是最终负责人

最后一条是原则性的：AI 生成的代码，最终责任人是开发者，不是模型。

这意味着：

• 每一行 AI 生成的代码都要经过 review。
• 涉及安全、支付、数据删除等敏感逻辑，必须人工逐行确认。
• 把 AI 当成“高级结对编程伙伴”，而不是“外包团队”。

9. 结语

命令行没有死，它正在换一种方式继续运转。AI 编程时代真正发生变化的，是人和工具之间的关系：从“人用命令行操作机器”变成“人用自然语言指挥 AI，AI 再操作命令行”。

如果你还没尝试过把CLAUDE.md上下文文档和需求描述文档加入项目，建议从下一个小需求开始尝试。先把项目结构和编码规范写清楚，再让 AI 接手执行，你会发现很多重复的命令行操作都可以交给 AI 完成，而你需要专注的是把“意图”表达清楚——这本身就是 AI 编程时代最重要的能力。