企业官网建设流程全解析

1. 从“写不出一行代码”到“用AI搭出纪律系统”：这不是速成神话，而是可复现的工程化路径

我第一次打开Cursor时，连Python的print()括号该用英文还是中文都犹豫了三秒。那会儿我刚辞掉做了七年的行政岗，想转行做点技术相关的事，但不是为了当程序员——而是想解决自己身上最顽固的问题：项目启动容易、推进难、烂尾频繁。过去三年，我攒了17个半成品项目，最长的一个停在“环境配置完成”的README里。直到上个月，我决定把“管住自己”这件事，交给AI来执行。

这听起来像营销话术，但事实是：我用AI编程工具（主要是Cursor + Claude 3.5 Sonnet API）从零开始，一个月内完成了4个真实可用的小项目——一个自动归档微信读书笔记的CLI工具、一个根据日程动态生成周报草稿的Web服务、一个解析会议录音并提取待办事项的本地脚本、还有一个能读取Notion数据库并按规则触发提醒的轻量级调度器。它们都不大，最小的只有237行代码，最大的也不过1200行，但每一个都跑在了我的主力机上，每天自动执行。

关键不在于“做了4个”，而在于第4个项目彻底改变了我的工作流逻辑：它不再是一个被动响应需求的工具，而是一个主动干预行为的“纪律代理”（Discipline Agent）。它会在我连续两小时没提交Git、或某项任务超期未更新状态、或当天代码行数低于设定阈值时，弹出不可跳过的确认框；它会自动锁住我常刷的三个网站的Chrome标签页，直到我手动完成一项被标记为“高优先级”的子任务；它甚至能分析我上周的commit message情绪倾向，如果检测到“fix bug”出现频率超过70%，就强制推送一篇《为什么你总在修bug而不是设计》的内部文章到我的阅读列表。

这个系统没有用任何现成的Agent框架（LangChain/LlamaIndex这类），也没有接入外部大模型API做实时推理——它的核心是一套基于状态机+规则引擎+本地缓存的轻量级闭环。所有判断都在本地完成，响应延迟<80ms，数据完全不出设备。它不是AI替我写代码，而是我把自己的拖延模式、决策盲区、执行断点，一条条翻译成机器可执行的if-else和定时任务。一个月后回头看，真正让我突破的，不是学会了怎么调API，而是终于搞懂了：所谓AI编程，本质是把人类模糊的自我认知，编译成计算机精确的执行指令。

如果你也经历过“收藏一堆AI编程教程→试了三天→卡在环境配置→放弃→再收藏”的循环，这篇就是为你写的。它不讲“AI多强大”，只拆解我亲手踩过的19个具体坑——从提示词写错导致生成代码无限递归，到本地Agent状态同步失败引发的双重提醒风暴，再到用错Git工作区导致整个纪律系统回滚丢失。这些坑，每一个都对应着AI编程中真实存在的“人机语义鸿沟”。

2. 四个项目演进路线：为什么必须从CLI工具开始，而不是直接上Web服务？

很多人一上来就想做个“能自动写PPT的AI Agent”，结果三天后还在纠结前端框架选React还是Vue。我的路径反其道而行：所有项目都从命令行界面（CLI）起步，且前三个项目全部拒绝网络请求、不依赖数据库、不涉及用户界面。这不是保守，而是刻意制造“低带宽交互”，逼自己看清AI生成代码的真实能力边界。

2.1 第一个项目：微信读书笔记自动归档CLI（耗时3天）

目标极其简单：每天凌晨2点，自动把微信读书最新一页的划线笔记，保存为Markdown文件，按日期归档到/notes/2024/06/15.md。
我原以为这是个“复制粘贴就能跑”的活，结果第一版提示词是：“帮我写个Python脚本，从微信读书导出笔记并保存”。Cursor生成的代码直接调用了requests.get("https://iwenxue.com/api/notes")——一个根本不存在的接口。我花了6小时才意识到：AI不知道微信读书根本没有公开API，它只是把“导出笔记”这个词，匹配到了它训练数据里最常见的实现方式（调HTTP接口）。

真正的解法，是换思路：微信读书iOS版支持“分享到微信”功能，而分享内容是纯文本。我用Mac自带的Automator捕获分享动作，将文本临时存入剪贴板，再用Python的pyperclip读取。整个流程变成：

# 伪代码逻辑，实际代码由AI生成后我手动修正 import pyperclip import time from datetime import datetime def get_notes_from_clipboard(): # 等待用户手动触发微信读书分享（需提前设置快捷键） print("请现在在微信读书中长按划线文字 → 分享 → 微信 → 文件传输助手") time.sleep(10) # 给用户操作留出时间 return pyperclip.paste() def save_to_md(content): date = datetime.now().strftime("%Y/%m/%d") path = f"notes/{date}.md" with open(path, "a") as f: f.write(f"\n\n---\n{content}\n")

提示：这里的关键转折点，是我把“从App获取数据”这个模糊需求，拆解成了“用户操作路径+系统级剪贴板监听”两个可执行步骤。AI擅长补全代码细节，但无法凭空发明交互范式——人类必须先定义好“人机协作的物理接口”，AI才能在其上构建逻辑。

2.2 第二个项目：周报生成Web服务（耗时5天，含2次推倒重来）

目标升级：读取我日历中的会议事件，结合当天Git commit记录，生成一份带数据图表的周报HTML。
我犯的第一个致命错误，是让AI直接生成Flask路由。它生成的代码里有@app.route('/report')，但没处理静态文件路径，导致CSS加载失败；更严重的是，它默认用sqlite3存日历数据，而我的日历在Outlook，需要调用Microsoft Graph API——这又回到了“AI虚构接口”的老问题。

第二次尝试，我彻底放弃让AI设计架构，改为分层交付指令：

• 第一层（我写）：明确输入源格式——“日历数据将以JSON文件形式提供，路径为./data/calendar.json，结构为[{"start":"2024-06-10T09:00","title":"需求评审","attendees":["zhangsan"]}]”；
• 第二层（AI写）：只负责解析该JSON、统计会议时长、生成Markdown；
• 第三层（我写）：用pandoc把Markdown转HTML，用wkhtmltopdf转PDF。

最终交付的代码只有3个文件：parse_calendar.py（AI生成）、generate_report.py（AI生成）、build.sh（我手写）。Web服务？根本没做。我用python -m http.server 8000起个静态服务器，把生成的HTML放进去，用浏览器打开就行。所谓“Web服务”，在这里降维成了“本地文件生成器+简易HTTP服务”。

2.3 第三个项目：会议录音待办提取脚本（耗时4天，核心在音频预处理）

目标：上传MP3会议录音，自动识别说话人，提取“ACTION ITEM: xxx”格式的待办事项。
AI生成的代码直接调用whisper.transcribe()，但没考虑音频采样率。我的录音是iPhone录的44.1kHz，而Whisper默认期望16kHz，导致识别准确率暴跌。更隐蔽的坑是：AI生成的正则表达式r"ACTION ITEM:\s*(.+)"会把“Action item: follow up with client”匹配成“follow up with client”，但也会把“Let's action item this”错匹配成“this”。

解决方案分三步：

1. 前置FFmpeg转码（我手写）：ffmpeg -i input.mp3 -ar 16000 -ac 1 -c:a libmp3lame output_16k.mp3；
2. AI生成Whisper调用代码（限定输入参数）：“用whisper.load_model('base')，传入output_16k.mp3，返回text字段”；
3. 后处理规则强化（我手写）：不用正则，改用字符串分割+关键词锚定——先splitlines()，对每行strip()后检查是否以“ACTION ITEM:”开头，再取冒号后第一个非空字符开始的内容。

注意：这里暴露了AI编程最危险的幻觉——它默认所有输入都是“干净数据”。而真实世界里，80%的工程时间花在数据清洗和格式适配上，这部分必须由人类定义规则，AI只负责执行。

2.4 第四个项目：纪律系统Agent（耗时18天，前15天都在重构前三项目）

当三个项目各自独立运行后，我发现了新问题：它们之间毫无关联。周报生成器不知道笔记归档是否完成，会议待办脚本不关心Git提交是否达标。于是第四个项目诞生——它不新增功能，而是给前三项目装上“神经系统”。

我给它定了三条铁律：

• 无中心化存储：所有状态存在本地SQLite，表结构只有三列key TEXT PRIMARY KEY, value TEXT, updated_at TIMESTAMP；
• 无实时通信：各项目通过读写同一数据库表交换状态，比如笔记归档完成后写入last_note_sync = "2024-06-15T02:00:00"；
• 无外部依赖：所有判断逻辑用SQL或Python内置函数完成，禁用任何requests、urllib。

最终系统包含5个独立进程：

• watcher_git.py：每5分钟查Git log，更新git_last_commit；
• watcher_notes.py：每小时检查notes/目录最新文件，更新last_note_sync；
• scheduler.py：主调度器，读取所有状态，按规则触发动作；
• notifier.py：执行通知（AppleScript弹窗/终端提示）；
• lock_browser.py：调用macOS的defaults write com.google.Chrome NSAppSleepDisabled -bool YES临时禁用Chrome。

这五个进程彼此不认识，只认数据库里的key-value。Agent的“智能”，来自人类预先编码的规则组合，而非模型实时推理。比如“连续两小时无Git提交”的判断，是scheduler.py执行SQL：SELECT COUNT(*) FROM status WHERE key='git_last_commit' AND value < datetime('now', '-2 hours')。

3. 踩坑实录：19个具体错误与修复方案（附原始提示词和修正后指令）

AI编程最大的陷阱，不是它写错代码，而是它写得“太像对的代码”——表面语法完美，实则逻辑错位。以下是我一个月内记录的19个典型错误，每个都标注了原始提示词、AI生成的错误代码片段、错误原因、以及我如何用“人类指令重写”修复。

3.1 提示词层面的坑：模糊动词导致逻辑坍塌

错误1：用“处理”代替“转换”

• 原始提示词：“帮我处理微信读书笔记，保存为Markdown”
• AI生成：def process_notes(notes): return notes.upper()（把文本转大写）
• 原因：“处理”在自然语言中含义过泛，AI按NLP任务惯例理解为“文本预处理”
• 修正指令：“把微信读书笔记的原始文本（含‘—’分隔线和emoji）转换为标准Markdown：1. 删除所有emoji；2. 将‘—’替换为‘---’；3. 每段前加‘> ’形成引用块”

错误2：省略主语导致上下文丢失

• 原始提示词：“读取日历数据，生成周报”
• AI生成：with open('calendar.json') as f: data = json.load(f)（硬编码路径）
• 原因：AI不知道“日历数据”对我而言是Outlook导出的outlook_export.json，且路径在~/Downloads/
• 修正指令：“读取用户主目录Downloads文件夹下的outlook_export.json文件，该文件由Outlook导出，结构为……（给出完整JSON Schema）”

错误3：混淆“应该”和“必须”

• 原始提示词：“周报应该包含会议时长统计”
• AI生成：if random.random() > 0.7: add_meeting_duration()（70%概率添加）
• 原因：AI把“应该”理解为“建议性要求”，而非强制逻辑
• 修正指令：“周报必须包含‘会议时长总计’字段，计算方式：遍历calendar.json中所有event，sum(event.duration_minutes)”

3.2 代码生成层面的坑：AI的“常识”不等于你的常识

错误4：假设不存在的库方法

• AI生成：os.path.get_creation_time(path)（实际应为os.stat(path).st_ctime）
• 修复：在提示词末尾加一句：“仅使用Python 3.9标准库，禁用所有第三方包，如pathlib、dateutil等”

错误5：忽略平台差异

• AI生成：subprocess.run(['open', '-a', 'Google Chrome', url])（Mac指令）
• 问题：我在Linux测试机上运行时报错
• 修复：明确指令：“生成跨平台浏览器打开代码：Mac用open -a 'Google Chrome'，Linux用xdg-open，Windows用start”

错误6：时间格式硬编码

• AI生成：datetime.strptime('2024-06-15', '%Y-%m-%d')
• 问题：当输入是15/06/2024时崩溃
• 修复：指令中指定：“所有日期解析必须兼容ISO格式（YYYY-MM-DD）和欧洲格式（DD/MM/YYYY），用dateutil.parser.parse()”

3.3 架构设计层面的坑：AI不懂“最小可行闭环”

错误7：过度设计状态管理

• AI生成：为纪律系统设计Redis集群+Pub/Sub消息队列
• 问题：单机运行，Redis安装配置耗时2小时，且无必要
• 修复：指令限定：“所有状态存储必须用SQLite，单文件，路径为./discipline.db，禁止任何网络服务依赖”

错误8：混淆进程与线程

• AI生成：threading.Thread(target=check_git).start()
• 问题：Python的GIL导致CPU密集型检查（如Git log解析）卡主线程
• 修复：指令明确：“所有周期性检查必须用subprocess.Popen启动独立进程，主程序只负责调度”

错误9：忽略资源泄漏

• AI生成：f = open('log.txt', 'a'); f.write(text)（未close）
• 修复：强制指令：“所有文件操作必须用with open() as f:上下文管理器”

3.4 运行时层面的坑：AI没见过你的真实环境

错误10：权限错误

• AI生成：os.remove('/tmp/old_file')
• 问题：/tmp下文件属主不是当前用户
• 修复：指令加一句：“所有文件操作路径必须在用户主目录下，如~/discipline/logs/”

错误11：路径分隔符

• AI生成：os.path.join('data', 'notes', '2024-06-15.md')
• 问题：在Windows上生成data\notes\2024-06-15.md，但我的脚本在Mac跑
• 修复：指令写死：“所有路径拼接必须用pathlib.Path，如Path.home() / 'discipline' / 'data' / 'notes'”

错误12：编码问题

• AI生成：open('notes.md', 'w').write(text)
• 问题：中文乱码
• 修复：指令强制：“所有文件打开必须指定encoding='utf-8'”

3.5 逻辑层面的坑：AI的“正确”可能违背业务本质

错误13：把“提醒”当成“阻断”

• AI生成：检测到超期任务，发邮件提醒
• 问题：我的目标是“强制中断刷手机”，邮件毫无约束力
• 修复：指令重定义：“提醒必须是不可跳过的GUI弹窗，且在用户点击‘确认完成’前，锁定Chrome进程”

错误14：混淆“完成”与“提交”

• AI生成：if git_status == 'clean': mark_task_done()
• 问题：“clean”指工作区无修改，但我的任务完成标准是“commit并push”
• 修复：指令明确：“任务完成标志是Git log中最近一条commit包含‘TASK-123’且已push到origin/main”

错误15：忽略副作用

• AI生成：os.system('killall Chrome')
• 问题：杀死所有Chrome窗口，包括我正在用的开发调试页
• 修复：指令细化：“只杀死标题含‘YouTube’或‘Zhihu’的Chrome窗口，用AppleScript实现”

3.6 部署层面的坑：AI没经历过你的发布流程

错误16：硬编码绝对路径

• AI生成：sys.path.append('/Users/xxx/project/src')
• 问题：同事clone后路径不同
• 修复：指令：“所有路径导入必须用Path(__file__).parent.parent动态计算”

错误17：忽略Python版本

• AI生成：print(f"Hello {name}")（f-string）
• 问题：生产机是Python 3.5
• 修复：指令开头声明：“目标Python版本：3.6+，禁用f-string，用.format()”

错误18：打包遗漏依赖

• AI生成：pip install requests（但我的项目禁用requests）
• 修复：指令末尾加：“本项目禁用所有HTTP客户端库，只允许标准库http.client”

错误19：日志覆盖

• AI生成：logging.basicConfig(filename='app.log')
• 问题：每次运行覆盖旧日志
• 修复：指令：“日志文件名必须包含日期，如app_20240615.log，用logging.FileHandler”

提示：这19个坑，每一个都对应着AI编程中一个关键认知节点。不要试图记住所有错误，而要建立“人类校验清单”：每次AI生成代码后，强制问自己三句话——它用的库我环境里有吗？它假设的输入格式我真能提供吗？它产生的输出是我下一步能直接用的吗？

4. Agent项目纪律系统：不是框架，而是可拆解的五层状态机

市面上的Agent框架（LangChain、LlamaIndex）强调“编排”“记忆”“工具调用”，但我的纪律系统反其道而行：它没有记忆模块，没有工具函数，没有LLM调用，只有五层状态机和一套人工编排的规则。这种“反潮流”设计，源于我对自身执行力缺陷的诚实诊断——我需要的不是更聪明的AI，而是更严格的执行约束。

4.1 第一层：输入源层（Input Sources）——定义“数据从哪里来”

这一层不写代码，只做三件事：

1. 固化数据获取路径：微信读书笔记→~/Downloads/wechat_notes.txt（由Automator定期写入）；
2. 标准化数据格式：所有输入JSON必须符合我定义的Schema，例如日历数据强制包含"duration_minutes": 45字段；
3. 设置采集频率：Git检查每5分钟一次，笔记检查每小时一次，会议录音处理手动触发。

关键经验：AI无法帮你决定数据源，但能帮你把已有数据源“翻译”成代码。人类必须先成为数据管道的设计师，AI才是管道工。

4.2 第二层：状态存储层（State Storage）——SQLite不是妥协，是刻意选择

我用SQLite不是因为“简单”，而是因为它天然满足纪律系统的三大需求：

• 原子性：BEGIN TRANSACTION; UPDATE ...; COMMIT确保状态更新不被中断；
• 单文件：discipline.db可直接rsync备份，无需考虑数据库dump；
• 零配置：sqlite3.connect('./discipline.db')一行代码搞定，无服务进程。

表结构极简：

所有状态更新都走同一条SQL：

INSERT OR REPLACE INTO status (key, value, updated_at) VALUES ('git_last_commit', ?, datetime('now'));

注意：这里没有ORM，没有Migration，没有连接池。当你的状态不超过10个key时，SQLite的裸SQL比任何ORM都快且可靠。

4.3 第三层：规则引擎层（Rule Engine）——用SQL和Python内置函数替代LLM

纪律系统的核心判断，全部写在scheduler.py的check_rules()函数里。例如“连续两小时无Git提交”的规则：

def check_git_stale(): conn = sqlite3.connect('./discipline.db') cursor = conn.cursor() cursor.execute(""" SELECT value FROM status WHERE key = 'git_last_commit' AND datetime(value) < datetime('now', '-2 hours') """) if cursor.fetchone(): # 触发锁浏览器动作 lock_chrome_until(datetime.now() + timedelta(minutes=30))

另一个规则“当日代码行数低于50行”：

def check_code_volume(): # 用git log --oneline统计今日commit行数 result = subprocess.run( ['git', 'log', '--since="today midnight"', '--oneline'], capture_output=True, text=True ) lines = len(result.stdout.strip().split('\n')) if result.stdout.strip() else 0 if lines < 50: send_terminal_alert("今日代码量不足！请专注写代码")

关键洞察：真正的Agent智能，不在于调用多少个API，而在于规则组合的严密性。我写了17条规则，每一条都对应我过去踩过的具体坑。

4.4 第四层：执行器层（Actuators）——让代码拥有“物理触感”

纪律系统之所以有效，是因为它能干预我的物理行为：

• GUI弹窗：用AppleScript调用osascript -e 'display alert "请完成TASK-001" buttons {"确认"}'；
• 进程控制：os.system('killall "Google Chrome"')（配合白名单过滤开发用Chrome）；
• 终端锁定：os.system('say "时间到，请停止刷手机"')（语音强制打断）。

所有执行器都遵循同一原则：动作必须不可逆、不可跳过、有明确截止时间。比如锁Chrome，不是“弹窗询问”，而是直接killall，然后启动一个倒计时30分钟的sleep 1800 && open -a "Google Chrome"恢复进程。

4.5 第五层：反馈闭环层（Feedback Loop）——用日志驱动持续优化

系统每天生成feedback.log，记录所有触发的规则和执行结果：

2024-06-15 14:22:01 [RULE] git_stale_triggered -> locked_chrome_for_30min 2024-06-15 14:52:01 [ACTION] chrome_unlocked 2024-06-15 15:05:22 [RULE] code_volume_met -> sent_success_alert

我每周手动分析这份日志，找出高频触发的规则——如果“会议待办未处理”连续三天触发，说明我的会议纪要流程有问题，需要优化；如果“笔记未同步”每周触发5次，说明Automator触发时机不对，要调整。

经验总结：Agent的价值不在自动化程度，而在反馈颗粒度。我的系统不追求100%自动，而追求100%可追溯——每一次干预，都留下可分析的日志证据链。

5. 为什么不用现成Agent框架？LangChain的“高级感”恰恰是纪律系统的最大敌人

看到这里，你可能会问：为什么不直接用LangChain搭个Agent？毕竟它有Memory、Tool、Orchestration，听着就专业。我的答案很直白：LangChain解决的是“如何让AI更聪明地调用工具”，而我的纪律系统解决的是“如何让人类更笨地遵守规则”。这两个目标，南辕北辙。

5.1 LangChain的三大“聪明陷阱”

陷阱1：抽象层掩盖真实成本
LangChain的Tool封装，让你觉得“调用天气API”和“读取本地文件”是同一抽象层级。但现实中：

• 天气API调用失败，最多返回空数据；
• 本地文件读取失败，意味着整个纪律系统瘫痪。
  我宁愿手写10行open()代码，也不愿引入Tool抽象带来的异常处理复杂度。

陷阱2：Memory机制违背纪律本质
LangChain的ConversationBufferMemory会把历史对话存下来，让AI“记住”上下文。但我的纪律系统需要的是遗忘——昨天的Git提交记录，对今天的判断毫无意义。我故意设计SQLite只存最新状态，删掉所有历史表。真正的纪律，是每一次判断都基于当下事实，而非历史包袱。

陷阱3：Orchestration增加单点故障
LangChain的AgentExecutor负责协调多个Tool，但它本身就成了故障点。一旦AgentExecutor.run()抛异常，整个流程中断。而我的五层状态机，每一层都是独立进程：watcher_git.py挂了，scheduler.py依然能读取旧状态做判断；notifier.py崩溃，lock_browser.py照常执行。去中心化不是技术选择，而是容错刚需。

5.2 我的“反框架”技术栈选择逻辑

这个栈看起来“过时”，但它满足纪律系统的核心指标：

• 启动延迟 < 200ms（scheduler.py从启动到完成一次检查）；
• 单次故障影响 < 1个功能模块（进程隔离）；
• 部署复杂度 = 0（git clone && chmod +x setup.sh && ./setup.sh）。

5.3 当你真的需要框架时：三个必须跨越的门槛

我并非全盘否定Agent框架，而是说：在你用框架之前，必须先亲手用原始工具造一遍轮子。这是我给自己设的门槛：

1. 能手写状态机：在不用任何框架的情况下，用SQLite+Python实现完整的状态流转（如：pending → processing → success/fail → retry）；
2. 能定义工具契约：明确每个“工具”（函数）的输入格式、输出格式、失败码、超时时间，且所有契约文档化；
3. 能画出数据血缘图：标出每个数据点从产生、存储、加工到消费的完整路径，且每条路径都有对应的监控埋点。

只有跨过这三道坎，你才真正理解LangChain的Tool、Memory、AgentExecutor在解决什么问题。否则，你只是在用高级玩具，重复制造新的技术债。

最后分享一个真实案例：我曾用LangChain搭过一个“自动写周报”的Demo，它能调用日历API、Git API、甚至用LLM润色文字。但上线三天后，它因为GitHub API限流失败，导致整个周报生成中断。而我的纪律系统，即使Git API失效，它依然能读取本地.git/logs/HEAD文件继续工作——真正的鲁棒性，来自对底层数据源的掌控力，而非框架的华丽包装。

我现在的桌面，还开着那个最原始的CLI笔记归档器窗口。它没有UI，没有API，没有云同步，但它每天凌晨2点准时运行，把我的思考碎片存进notes/目录。这或许就是AI编程最朴素的真相：技术的价值，不在于它多炫酷，而在于它能否成为你生活里那个沉默却可靠的执行伙伴。