用单文件驱动AI实现代码自治：从任务分解到闭环执行的工程实践 1. 项目概述一个文件如何让AI代码“活”起来最近在折腾AI编程助手时我一直在思考一个问题我们每天让Claude、GPT这类模型生成大量代码片段但这些代码往往只是躺在编辑器里的“死文本”。它们需要你手动复制、粘贴、创建文件、配置环境、安装依赖最后才能运行起来。整个过程繁琐且割裂打断了“思考-实现”的流畅性。有没有一种方法能让AI生成的代码直接“活”过来变成一个可以自动执行、甚至能自我迭代的“开发团队”这就是“I Turned Claude Code Into a Dev Team With One File”这个项目的核心构想。它不是一个复杂的框架而是一个极其简单的思维转变和工具组合用一个单独的、结构化的“任务清单”文件驱动AI模型去自动执行它自己写出的代码。听起来有点绕简单说就是让AI不仅当“程序员”还当“项目经理”和“执行者”。你不再需要逐条复制AI的建议而是给它一个目标和一个“工作流引擎”它就能自动分解任务、编写代码、执行测试、修复问题直到产出最终结果。这个想法的价值在于它将人从重复性的“中间人”角色中解放出来。我们不再需要充当AI大脑和本地终端之间的传令兵。无论是搭建一个简单的Web服务器、编写一个数据清洗脚本还是初始化一个复杂的项目脚手架你只需要用自然语言描述最终想要什么然后启动这个“单文件引擎”剩下的规划、编码、调试、部署工作都可以交给这个由AI驱动的“虚拟开发团队”去完成。这极大地提升了原型验证和自动化脚本开发的效率尤其适合独立开发者、技术管理者以及需要快速验证想法的场景。2. 核心设计思路从“代码生成”到“任务自治”这个项目的魔力并不在于用了多么高深的技术而在于对现有工具链AI模型命令行脚本的一次创造性重组。其核心设计思路可以拆解为三个层次任务抽象层、AI驱动层和执行反馈层。2.1 任务抽象层将目标转化为可执行的“工单”传统的AI编程交互是线性的你提问 - AI回复代码 - 你手动操作。而本项目的思路是环状的你定义最终目标 - 系统将其转化为结构化任务 - AI为每个任务生成代码和指令 - 系统执行 - 将结果反馈给AI进行下一步决策。实现这一点的关键就是那个“One File”。这个文件通常是一个YAML或JSON格式的配置文件我更喜欢称它为“项目工单Project Ticket”。它不包含任何业务逻辑代码只包含对目标的描述和任务框架。一个基础的工单结构可能包含以下部分project_goal: “构建一个简单的Flask API提供用户注册和登录功能并使用SQLite存储数据。” success_criteria: - “运行 python app.py 后服务器在本地5000端口启动。” - “访问 /docs 能看到自动生成的API文档。” - “能通过 /register 端点成功创建新用户。” - “能通过 /login 端点验证用户并返回令牌。” constraints: - “使用Python 3.8” - “使用Flask和Flask-SQLAlchemy” - “密码需要哈希存储” - “项目结构清晰包含 requirements.txt” tasks: [] # 初始为空由AI填充这个工单文件定义了做什么Goal、做成什么样算成功Criteria以及有哪些限制Constraints。tasks列表初始为空它将作为AI分解任务后的“工作清单”存放地。这种结构化的描述比一段模糊的自然语言提示词更能让AI理解需要交付的具体产出物。2.2 AI驱动层让模型扮演“技术主管”角色有了清晰的工单下一步就是让AI来扮演“技术主管”或“高级工程师”的角色。这里通常需要调用AI模型的API如Anthropic的Claude API或OpenAI的GPT API。驱动层的核心函数需要完成以下工作任务分解Planning将工单中的project_goal发送给AI要求它输出一个具体的、有序的任务列表Task List。每个任务应该是一个原子操作例如“创建项目目录结构”、“编写app.py主文件”、“设计User模型类”、“编写注册端点逻辑”、“创建数据库初始化脚本”等。系统会把这个列表写回工单文件的tasks字段。任务执行Execution系统遍历tasks列表。对于每个任务再次调用AI将任务描述、当前项目上下文如已生成的文件列表、之前任务的执行结果或错误信息以及约束条件一并提交。AI的职责是生成为了完成这个任务所需的所有具体操作。这通常包括两部分代码生成Code需要创建或修改的源代码。Shell指令Commands需要运行的终端命令例如pip install -r requirements.txtpython init_db.py 或pytest tests/。上下文管理Context这是保持AI“记忆”连贯性的关键。系统需要维护一个不断增长的“项目上下文”它可能包括所有已生成文件的路径和内容摘要、已执行命令的历史及其输出尤其是错误输出、当前的项目状态如“数据库已初始化”、“服务器未启动”。每次与AI交互时这个上下文都会被作为背景信息发送确保AI不会做出矛盾或重复的操作。2.3 执行反馈层构建闭环的“开发-测试”流水线AI生成的Shell指令不会只显示在屏幕上而是会被一个安全的子进程执行器自动运行。这一层是整个系统从“纸上谈兵”变为“真枪实弹”的关键。安全执行沙盒绝不能盲目执行AI生成的任何命令。必须建立一个允许列表Allow List或命令前缀检查。例如只允许执行以pip install、python、echo、mkdir、cat等安全命令开头的指令。绝对禁止执行rm -rf /、curl | bash等高风险命令。一种更安全的做法是在一个临时Docker容器或虚拟环境中运行所有命令。结果捕获与解析执行命令后必须捕获其标准输出stdout、标准错误stderr以及退出码。这些结果至关重要它们将被格式化后反馈给AI。闭环反馈循环如果命令执行成功退出码为0系统会将成功结果纳入上下文并继续下一个任务。如果执行失败退出码非0或输出中包含错误关键词系统不会直接报错退出而是将完整的错误信息stderr反馈给AI并要求它“分析错误并给出修复方案”。AI可能会选择重试命令、修改之前生成的代码、或提出新的补救任务。这个过程模拟了一个真实的调试过程直到任务成功或达到重试上限。通过这三层的协作一个静态的“工单”文件就变成了一个动态的、具备自治能力的智能体。它自己规划、自己写代码、自己运行、自己调试而你只需要在开始时给出一个想法并在最终验收成果。3. 单文件引擎的架构与关键技术点理解了核心思路后我们来深入这个“一个文件”引擎的内部看看它具体是如何搭建起来的。我将这个核心文件命名为ai_dev_team.py它包含了整个自治系统的所有逻辑。下面拆解几个关键的技术模块。3.1 工单解析与状态管理模块这个模块负责读取和解析我们之前提到的YAML工单文件并维护整个项目的状态机。状态管理是协调AI与执行环境的核心。import yaml import os from dataclasses import dataclass, field from typing import List, Dict, Any, Optional dataclass class ProjectState: 项目状态数据类贯穿整个生命周期 goal: str success_criteria: List[str] constraints: List[str] tasks: List[Dict[str, Any]] field(default_factorylist) # 任务列表 completed_tasks: List[str] field(default_factorylist) # 已完成任务名 generated_files: Dict[str, str] field(default_factorydict) # 文件路径: 内容摘要 command_history: List[Dict[str, Any]] field(default_factorylist) # 命令历史 current_context: str # 当前AI对话的上下文摘要 classmethod def from_yaml(cls, yaml_path: str) - ProjectState: with open(yaml_path, r) as f: data yaml.safe_load(f) return cls( goaldata[project_goal], success_criteriadata[success_criteria], constraintsdata[constraints], tasksdata.get(tasks, []) ) def to_context_string(self) - str: 将当前状态转换为供AI理解的文本上下文 context f项目目标{self.goal}\n\n context f已完成任务{, .join(self.completed_tasks)}\n if self.completed_tasks else context f最近生成的文件{list(self.generated_files.keys())}\n if self.generated_files else # 附上最近1-2条命令的执行结果特别是错误信息 if self.command_history: recent self.command_history[-2:] for cmd in recent: context f 执行命令{cmd[command]}\n if cmd[exit_code] ! 0: context f命令失败退出码{cmd[exit_code]}\n{cmd[stderr][:500]}\n return context这个ProjectState类是整个系统的大脑。to_context_string方法尤为重要它负责将复杂的项目状态压缩成一段精炼的文本作为每次与AI对话的“前情提要”确保AI始终知道自己做到哪一步了遇到了什么问题。3.2 AI客户端与提示词工程模块与AI模型的交互并非简单的问答需要精心设计提示词Prompt来引导其扮演好“开发团队”的角色。我们需要为不同的阶段规划、执行、调试设计不同的系统指令System Prompt。import openai # 或 anthropic from tenacity import retry, stop_after_attempt, wait_exponential class AIClient: def __init__(self, model: str gpt-4, api_key: str None): self.client openai.OpenAI(api_keyapi_key) self.model model def _create_planning_prompt(self, state: ProjectState) - List[Dict]: 创建任务分解的提示词 system_msg 你是一个经验丰富的技术主管。请将下面的项目目标分解成一个具体、有序、可执行的任务列表。 每个任务应该是一个独立的、可在终端或代码编辑器中完成的原子操作。 以JSON数组格式回复每个任务是一个对象包含 name任务名和 description任务描述字段。 user_msg f项目目标{state.goal} 成功标准{state.success_criteria} 约束条件{state.constraints} 请生成任务列表。 return [ {role: system, content: system_msg}, {role: user, content: user_msg} ] def _create_execution_prompt(self, task: Dict, state: ProjectState) - List[Dict]: 创建任务执行的提示词 system_msg 你是一个全栈工程师正在按任务清单工作。你的职责是生成完成当前任务所需的确切代码和Shell命令。 请严格按照以下格式回复 **代码文件**如果需创建或修改 [文件路径] [语言] [代码内容] **Shell命令** [需要执行的命令] 如果任务不需要新代码或命令请说明原因。 user_msg f当前任务{task[name]} - {task[description]} 项目上下文 {state.to_context_string()} 请生成完成此任务所需的操作。 return [ {role: system, content: system_msg}, {role: user, content: user_msg} ] retry(stopstop_after_attempt(3), waitwait_exponential(multiplier1, min4, max10)) def call(self, messages: List[Dict], temperature: float 0.2) - str: 调用AI API包含重试逻辑 response self.client.chat.completions.create( modelself.model, messagesmessages, temperaturetemperature, # 低温度保证输出稳定性 max_tokens2000 ) return response.choices[0].message.content注意提示词的设计是成败的关键。系统指令必须清晰界定AI的角色和输出格式。要求AI以特定格式如JSON、明确的章节标题回复可以极大简化后续的结果解析。同时为API调用添加重试机制使用tenacity库是保障鲁棒性的必备操作能应对偶发的网络或API服务波动。3.3 安全命令执行与文件操作模块这是与操作系统交互的边界必须格外小心。import subprocess import shlex from pathlib import Path class SafeExecutor: ALLOWED_COMMAND_PREFIXES [python, pip install, echo, mkdir, cd, ls, cat, pytest, curl -O] def execute_command(self, command: str, cwd: str .) - Dict[str, Any]: 安全地执行Shell命令 # 1. 安全检查 if not any(command.startswith(prefix) for prefix in self.ALLOWED_COMMAND_PREFIXES): return { command: command, exit_code: -1, stdout: , stderr: f错误命令{command}不在允许列表中。, safe_to_run: False } # 2. 执行命令 try: # 使用shellFalse并传递参数列表更安全 args shlex.split(command) result subprocess.run( args, cwdcwd, capture_outputTrue, textTrue, timeout30 # 防止命令长时间挂起 ) return { command: command, exit_code: result.returncode, stdout: result.stdout, stderr: result.stderr, safe_to_run: True } except subprocess.TimeoutExpired: return {command: command, exit_code: -1, stdout: , stderr: 命令执行超时30秒。, safe_to_run: True} except Exception as e: return {command: command, exit_code: -1, stdout: , stderr: f执行异常{str(e)}, safe_to_run: True} def write_file(self, filepath: str, content: str): 将AI生成的代码写入文件 path Path(filepath) path.parent.mkdir(parentsTrue, exist_okTrue) # 自动创建目录 path.write_text(content, encodingutf-8) print(f[文件已创建] {filepath})这个执行器做了几件重要的事1) 通过白名单机制限制可执行的命令这是安全底线2) 使用subprocess.run并设置timeout避免恶意或错误命令导致进程卡死3) 自动创建不存在的目录让AI无需关心目录是否存在。3.4 主控制循环串联一切的“调度器”最后我们需要一个主函数来串联所有模块形成完整的工作流。def main(project_ticket_path: str): # 1. 初始化 state ProjectState.from_yaml(project_ticket_path) ai_client AIClient() executor SafeExecutor() # 2. 阶段一任务规划 if not state.tasks: print( 阶段1AI任务规划 ) planning_prompt ai_client._create_planning_prompt(state) planning_response ai_client.call(planning_prompt) # 解析AI返回的JSON填充state.tasks # 此处需添加JSON解析逻辑略 print(f规划完成共{len(state.tasks)}个任务。) # 3. 阶段二任务执行与迭代 print(\n 阶段2任务执行 ) for i, task in enumerate(state.tasks): if task[name] in state.completed_tasks: continue # 跳过已完成任务在重试时有用 print(f\n--- 执行任务 {i1}/{len(state.tasks)}: {task[name]} ---) max_retries 3 for retry_count in range(max_retries): # 生成执行指令 execution_prompt ai_client._create_execution_prompt(task, state) execution_response ai_client.call(execution_prompt, temperature0.1) # 更低温度保证确定性 # 解析响应提取代码块和命令块需编写解析函数略 code_blocks parse_code_blocks(execution_response) command_blocks parse_command_blocks(execution_response) # 执行代码写入和命令运行 for filepath, code in code_blocks.items(): executor.write_file(filepath, code) state.generated_files[filepath] code[:100] ... # 存储摘要 all_commands_succeeded True for cmd in command_blocks: result executor.execute_command(cmd) state.command_history.append(result) print(f[命令] {cmd}) if result[stdout]: print(f[输出] {result[stdout][:200]}...) if result[exit_code] ! 0: print(f[错误] {result[stderr][:500]}) all_commands_succeeded False # 将错误信息融入state.context准备下一次重试 break # 一个命令失败就跳出当前任务的重试循环 if all_commands_succeeded: state.completed_tasks.append(task[name]) print(f任务 {task[name]} 完成。) break # 跳出重试循环进行下一个任务 else: print(f任务 {task[name]} 第{retry_count1}次尝试失败将错误反馈给AI并重试...) # 错误信息已通过 state.to_context_string() 在下一次循环中反馈给AI else: # for循环正常结束即重试了max_retries次都失败 print(f警告任务 {task[name]} 在{max_retries}次重试后仍失败跳过。) # 4. 最终报告 print(f\n 执行结束 ) print(f总任务数{len(state.tasks)}) print(f成功{len(state.completed_tasks)}) print(f失败{len(state.tasks) - len(state.completed_tasks)})这个主循环清晰地展示了“规划-执行-反馈”的自治流程。它为每个任务提供了最多3次重试机会每次失败都会将具体的错误日志反馈给AI让它有机会自我修正这模拟了真实的开发调试过程。4. 实战演练从零构建一个天气查询CLI工具理论说再多不如动手一试。让我们用一个具体的例子看看这个“单文件开发团队”如何从零开始构建一个简单的命令行天气查询工具。我们的目标是创建一个Python脚本可以通过城市名查询实时天气并将结果以美观的格式打印在终端。4.1 准备工单文件首先我们创建项目工单weather_cli_ticket.yamlproject_goal: “创建一个名为‘weather-cli’的Python命令行工具。用户可以通过命令‘weather 城市名’例如‘weather 北京’查询该城市的实时天气信息并在终端中以清晰、带颜色的格式显示温度、湿度、天气状况和风力。” success_criteria: - “在项目根目录执行‘python -m pip install -e .’后工具‘weather’应作为全局命令可用。” - “运行‘weather 北京’能成功返回结构化的天气信息而不是报错或乱码。” - “工具应能处理用户输入错误如城市不存在并给出友好的错误提示。” - “代码结构清晰包含setup.py、主程序文件、配置文件存放API密钥和README.md。” constraints: - “使用Python 3.8” - “使用‘requests’库调用免费的公共天气API例如OpenWeatherMap” - “使用‘click’或‘argparse’库处理命令行参数” - “使用‘colorama’或‘rich’库为终端输出添加颜色” - “API密钥必须从环境变量或配置文件读取不能硬编码在源码中” tasks: []这个工单非常具体定义了功能、交付标准和技术栈为AI提供了明确的行动指南。4.2 运行引擎并观察过程在命令行中运行我们的核心引擎文件python ai_dev_team.py weather_cli_ticket.yaml接下来你会看到一场自动化的“开发表演”规划阶段AI例如GPT-4会读取工单并生成一个类似以下的任务列表task1: “初始化项目结构创建项目目录weather-cli并初始化git仓库可选。”task2: “创建setup.py文件定义包信息和安装依赖requests, click, colorama。”task3: “编写核心配置文件config.py实现从环境变量WEATHER_API_KEY读取API密钥的逻辑。”task4: “编写天气API客户端模块weather_api.py封装对OpenWeatherMap API的调用包括错误处理。”task5: “编写主命令行入口点cli.py使用click定义‘weather’命令解析城市参数。”task6: “在主程序中集成API客户端和配置实现查询、数据解析和彩色终端输出。”task7: “创建README.md文件说明安装、配置和使用方法。”task8: “执行安装命令pip install -e .验证工具是否可全局调用。”task9: “运行测试命令weather London验证功能是否正常。”执行阶段引擎开始逐个执行任务。你会看到它自动创建目录和文件写入AI生成的代码。例如在task4中AI可能会生成如下代码# weather_api.py import requests import os from config import API_KEY, BASE_URL class WeatherAPI: staticmethod def get_weather(city: str): params {q: city, appid: API_KEY, units: metric, lang: zh_cn} try: response requests.get(f{BASE_URL}/weather, paramsparams, timeout10) response.raise_for_status() return response.json() except requests.exceptions.RequestException as e: raise Exception(f查询天气失败{e})紧接着引擎会执行task8的命令pip install -e .。如果因为网络问题导致pip install失败引擎会捕获错误输出如“Connection timeout”并将其反馈给AI。AI在下一轮重试中可能会建议“重试命令”或“检查网络连接”引擎则会再次执行pip install。验证阶段所有任务执行完毕后引擎会提示完成。你可以手动运行最终生成的测试命令weather 北京来验证这个完全由AI驱动构建的工具是否工作。4.3 关键细节与实操心得通过这个实战案例我总结出几个让“单文件开发团队”更高效、更可靠的关键点API选择与密钥管理在工单的constraints里指定使用OpenWeatherMap这样的免费API是明智的。AI在生成config.py时通常会建议从环境变量读取密钥。实操心得你可以在运行引擎前先在终端导出环境变量export WEATHER_API_KEYyour_key这样AI生成的代码就能直接使用。更好的做法是在工单中增加一个“预检查”任务让AI生成一个脚本来自动提醒用户设置环境变量。依赖管理的确定性AI可能会在setup.py或requirements.txt中指定模糊的版本号如requests。这可能导致后续安装的库版本不兼容。解决方案在constraints中明确加入“使用固定的主要版本依赖例如requests2.25,3.0”引导AI生成更精确的依赖声明。错误处理的完备性观察AI生成的错误处理代码。在上述weather_api.py中它使用了raise_for_status()和通用的Exception。这不错但不够友好。你可以在工单的success_criteria中强调“给出友好的错误提示”AI可能会进一步优化返回如“城市未找到”或“网络连接异常请检查后重试”等更具体的用户提示。输出格式的美观性要求使用colorama或rich库AI生成的输出代码通常会包含ANSI颜色代码或rich的Panel组件这使得最终的命令行工具看起来非常专业。这是一个通过约束条件轻松提升项目质量的例子。这个实战过程完美诠释了“单文件驱动”的理念你只需编写一个约20行的YAML工单描述清楚“想要什么”和“有什么要求”剩下的项目初始化、编码、依赖安装、甚至初步测试都可以交给这个自治系统去完成。你从执行者变成了监督者和验收者。5. 常见问题、局限性与进阶技巧尽管这个模式非常强大但在实际使用中你一定会遇到各种问题和挑战。以下是我在多次实践中积累的常见问题排查清单和进阶使用技巧。5.1 常见问题与排查指南问题现象可能原因排查与解决思路AI生成的任务列表过于笼统或顺序不合理提示词中关于“原子操作”和“有序”的指令不够强项目目标描述太模糊。1. 强化系统提示词例如“请将目标分解为最多10个步骤每个步骤必须对应一个可执行的命令或一个可创建/修改的特定文件。”2. 在project_goal中提供更具体的范例如“类似项目通常包含setup.py, src/目录, main.py等”。AI生成的代码有语法错误或逻辑错误AI模型本身的“幻觉”上下文窗口限制导致遗忘之前生成的代码结构。1. 在constraints中明确代码规范如“遵循PEP 8”“为函数和类添加类型注解”。2.启用“代码验证”步骤在引擎中增加一个环节在写入文件后对Python文件运行python -m py_compile file.py进行快速语法检查如有错误则将编译错误信息反馈给AI要求其修正。Shell命令执行失败非权限问题AI生成的命令参数错误、路径不存在或依赖未安装。1. 查看引擎打印的[错误]信息这是AI进行调试的依据。通常AI能根据具体的错误信息如ModuleNotFoundError: No module named click给出修复方案如先执行pip install click。2. 确保ALLOWED_COMMAND_PREFIXES包含了所有必要的命令前缀如python -m pip。项目陷入无限循环或重复失败某个任务经过最大重试次数后依然失败错误可能无法由AI自动修复如需要人工输入的API密钥无效。1. 引擎应设置全局超时或最大总任务数防止死循环。2. 对于需要人工干预的步骤如申请API密钥应在工单中明确将其作为一个“手动任务”AI生成的操作是“提示用户去某网站申请并设置环境变量”然后引擎暂停等待用户确认后再继续。生成的文件结构混乱或不符合预期AI对项目结构的理解有偏差。在constraints中提供项目结构样板。例如“项目必须遵循以下结构weather-cli/ setup.py README.md src/weather_cli/ __init__.py cli.py api.py config.py”。这能极大提高生成代码的组织性。5.2 模式局限性认知清醒地认识到当前模式的局限才能更好地利用它并非万能自动化它最适合套路化、有明确模式的任务如创建新项目脚手架、编写样板代码、实现标准CRUD API、编写数据迁移脚本等。对于需要深度创新、复杂算法设计或高度领域专业知识如内核驱动开发的任务它目前还难以胜任。成本与性能频繁调用高级别AI API如GPT-4会产生费用且速度不如本地执行。对于非常复杂的项目任务分解和迭代调试可能导致API调用次数剧增。安全性风险尽管有命令白名单但让AI自动生成和执行代码始终存在潜在风险。绝对不要在具有重要数据或权限的生产环境中直接运行此类引擎。应在隔离的容器、虚拟机或临时目录中进行。代码质量波动生成的代码质量取决于AI模型的能力、提示词的精细度和项目复杂度。它可能能写出“能跑”的代码但距离“优雅、高效、可维护”的工业级代码还有差距通常需要事后的人工审查和重构。5.3 进阶技巧与扩展思路当你熟悉基础模式后可以尝试以下进阶玩法让这个“开发团队”更强大多专家角色协作在提示词中引入“角色扮演”。你可以定义不同的AI角色如“系统架构师”、“后端开发”、“前端开发”、“测试工程师”并为每个角色分配不同的系统指令。在任务执行时根据任务类型如“设计数据库模型” vs “编写CSS样式”调用不同的角色模拟真实的团队协作。集成版本控制让引擎在关键节点如完成一个功能模块后自动执行git add和git commit并生成有意义的提交信息。这不仅能备份工作进度还能生成一份清晰的、由AI编写的开发日志。后置代码质量检查在引擎的最后阶段加入自动化代码质量检查。例如让AI自己运行black格式化代码、用pylint或ruff进行静态检查并根据检查结果生成新的修复任务。这能推动项目向更规范的方向发展。动态工单更新允许AI在执行过程中根据遇到的情况动态修改工单。例如AI在尝试调用某个API时发现其文档已更新它可以提议修改constraints中的API选择并为你生成一个需要“人工批准”的变更建议。“人类在环”审批对于关键操作如安装新的系统级依赖、向项目引入一个新的庞大框架、删除文件等引擎可以暂停并请求人工确认y/n。这实现了自动化与安全控制的平衡。这个“单文件开发团队”项目本质上是一种人机协同编程范式的探索。它并非要取代开发者而是将开发者从重复、琐碎、模式化的劳动中解放出来让我们能更专注于真正需要创造力、判断力和深层次思考的部分。从用一个YAML文件驱动AI构建一个天气CLI工具开始你可以逐渐将它扩展到更复杂的场景比如自动生成项目文档、编写单元测试套件、甚至辅助进行代码重构。它的边界取决于你如何设计那个作为起点的“工单”以及你如何迭代优化连接AI与计算机的这座“桥梁”。