企业官网建设流程全解析

做一个 AI 英语写作 APP，听起来像是把作文丢给大模型、让它挑挑语法错误就完事。真上手之后才发现，差得远了。这个项目如果只做“识别文本→调用模型→展示评语”，那它充其量是个 Demo。而真正能解决用户问题的，是“怎么让 AI 像一个有经验的批改老师一样，讲清楚哪里错了、为什么错、怎么改、以及这次写作到底暴露出哪些能力短板”。这篇内容适合正在规划 AI 教育类产品、或准备把大模型能力落地成具体功能的人参考，我会从项目定位、技术选型、核心功能拆解、踩坑实录到排查技巧，完整过一遍我在这类项目里的开发经验。

1. 项目定位与功能规划

1.1 先想清楚：用户要的是“被批改”，不是“被代写”

很多团队做英语写作工具，第一反应是“让 AI 帮用户写一篇高分作文”。这个方向我只体验了一次就放弃了——它的结果就是用户永远不会动笔，产品也失去了存在的意义。真实的用户场景是：英语学习者（准备四六级、雅思托福，或者单纯想提升学术写作能力的人）已经写了一版作文，迫切需要有人帮他找出具体问题，比如“这里时态用错了”“这个搭配在英文里不常见”“这段和上一段的逻辑衔接很别扭”。他们想要的是“被批改”的反馈，而不是一个替代思考的生成器。

所以项目定位在第一轮需求讨论时就应该明确：AI 英语写作 APP 不是写作生成工具，而是写作教练工具。所有功能围绕“输入作文→生成反馈→指导修改→追踪进步”这条闭环展开，而不是“给我一个主题，帮我写一篇满分作文”这种一次性输出。

这一个定位决定了后续所有设计：拍照识别是为了“录入已经写好的作文”，批改反馈要“逐句解释而不是给一个笼统分数”，学习报告要“追踪多次写作的弱项变化”。如果一开始把产品定义成“AI代写”，后面功能设计、模型 Prompt、数据统计全都会跑偏。

1.2 MVP 功能边界：砍掉一切非核心

在项目起步阶段，真正值得做进第一版的功能只有三个：

• 拍照识别作文（手写体和打印体都要支持），自动转成可编辑的电子文本；
• AI 批改，按“全文总评—段落点评—逐句批改”三层结构给出反馈，每个错误都要有“原句、问题分析、修改建议、参考改写”；
• 批改记录与弱项追踪，每次批改沉淀出用户的语法、词汇、搭配、逻辑四个维度的能力评分，方便用户看到自己的进步趋势。

初始计划里还有“范文推荐”“AI 润色后一键导出 PDF”“社区分享”这些功能，但我在初版全部砍掉了。原因很简单：MVP 的核心是要验证“AI 批改反馈质量是否足够好到让用户愿意持续使用”。功能越多，开发越分散，而且用户真正去用的功能可能就是每天拍一篇作文、看批改、按建议修改，其他功能大多是锦上添花。不如先把核心链路做扎实，等用户反馈出来了，再决定下一版加什么。

这个取舍建议每个做 AI 应用的人认真对待。教育类产品尤其要注意：用户的时间是有限的，你的产品层级越深、功能越杂，用户到达核心价值的路径就越长。而写作批改的核心价值就是“反馈质量”，其他都是次要的。

2. 技术方案选型与架构设计

2.1 为什么选大模型而不是传统语法检查规则库

做写作批改功能时，第一反应可能是用传统的语法检查工具（比如各种开源的词性标注 + 语法规则匹配方案）。这类方案优点是响应快、便宜、可控，但缺陷非常明显：它只能查出比较明显的语法错误（比如主语谓语不一致、冠词缺失），对“这个词在这个语境下用得不自然”“这两句话之间的逻辑跳跃太大”“这段和全文论点不一致”这类高层次写作问题完全无能为力。

而英语写作批改恰恰是“高分和及格分的差距”往往不在简单语法，而在用词准确性、搭配地道性、句间连贯性、论证充分性。传统规则库没法在这些维度给出有价值的反馈。所以我在技术评估阶段就确定了：必须用大语言模型做语义层面的分析和批改。这个决定是整个项目能否成立的关键。

在模型选型上，核心要看三点：指令遵循能力（能不能严格按你要求的格式输出结构化结果）、长文本处理能力（批改一篇 300~500 词的作文，加上批改要求、示例，上下文很容易超过 4000 tokens）、对细节的敏感度（能不能发现“逻辑衔接不畅”“论证深度不够”这类不那么显眼的问题）。按照这个标准筛选，当时主流商用大模型里，能力天花板较高的一档基本都能满足，关键还是看你怎么引导。

2.2 客户端直连还是后端聚合：这不是一个可以偷懒的选择

很多初做 AI 功能的团队，会为了省事让客户端直接调用模型接口。我一开始也这么考虑过，但很快否掉了。原因有几层：

第一，密钥安全。客户端直连意味着模型密钥要内置在 APP 里，逆向提取只是时间问题。第二，成本控制。没有后端统一管控，一旦被刷接口或者出现恶意调用，费用很快就失控。第三，稳定性。模型接口偶尔会超时、限流，如果客户端直接依赖它做实时批改，体验会非常脆弱。第四，数据沉淀。批改记录、用户画像、错误分布统计这些核心资产都需要写进自己的服务端，而不是让所有数据都直接经过第三方接口后无沉淀。

所以我的架构设计分成四层：

• 接入层：客户端负责拍照、文本编辑、结果展示；
• 服务层：负责接收作文文本、组装 Prompt、发起模型调用、解析返回结果、存储批改记录；
• 模型层：商用大模型接口，承担语义理解与文本生成；
• 数据层：用户信息、作文记录、批改结果、弱项统计。

服务层是核心。所有 Prompt 模板、参数配置、结果后处理逻辑都在这层，后续如果想换模型供应商或者调整批改策略，只需要改这一层，客户端完全不用动。

2.3 一条批改链路拆成三次模型调用：为什么要并行而不是一次搞定

这里有个很容易踩的坑：以为一次模型调用就能同时完成“全文总评、段落点评、逐句批改”。实际上，把三个不同粒度的任务塞进同一个请求，模型往往会在某个维度上偷懒。让它同时做“宏观文章评价”和“逐句细扣细节”时，它的注意力会被分散，常见表现是：总评写得头头是道，但逐句批改漏掉一半错误；或者逐句批改很细，但总评流于空话。

所以我把批改流程拆成三条并行的分析链路：

• 全文链路：输入整篇作文，输出总分、维度分（语法准确性、词汇丰富度、结构逻辑性、内容充实度）、总体评价、改进建议，要求评价具体到段落编号；
• 逐句链路：把全文按句子切分后，让模型对每个句子独立批改，输出错误定位（原句片段）、错误类型、问题解释、修改建议；
• 词汇链路：提取作文中的用词与搭配，判断哪些词汇使用不当或偏简单，给出更地道的高级替换建议。

三个链路并行调用，最后在服务层合并结果。这样做的好处是每个请求的任务边界都清晰，模型不需要在不同粒度的任务之间来回切换，输出质量明显提升。代价是调用次数变多、成本略微增加，但批改质量是这类产品的生命线，这个成本必须花。实际项目里，我用开源的并发库把三次调用并行发出，整体时延没有比单次调用多多少，完全可控。

3. 核心功能实现与关键细节

3.1 拍照识别与文本还原：拍歪了、反光、连笔字怎么处理

拍照识别是我在这个项目里最先开始做、也是前期耗时最多的部分。用户真实场景中会拿手机拍手写作文纸、打印的范文、课本上的段落，光照不匀、视角倾斜、桌面纹理干扰都很常见。直接调用通用 OCR 效果一般，原因在于通用 OCR 更多是优化“印刷体水平文本识别”，对于“手写连笔英文 + 倾斜视角 + 光线不均”这种情况，识别率会明显下降。

我的预处理方案是：拿到原始图像后，先做灰度化，再用自适应阈值做二值化来消除阴影干扰，然后用透视变换校正倾斜角度，最后把图像分区裁切后再送入 OCR 引擎。这里最关键的一点是：不要把整张纸直接丢给 OCR，一定要先做方向和版面的初步分析。否则打印体还好，手写体一旦有行间倾斜，识别结果会串行，批改环节根本没法用。

做文本还原的时候还有一个细节很多人容易忽略：OCR 出来的英文文本经常缺标点、单词中间多个空格、大小写混乱。直接拿这种文本去做逐句批改，模型会对句子的边界判断错乱。所以我加了一个文本清洗层：用规则把换行拼接成完整句子、修正明显的 OCR 误识别词（针对常见高频词的混淆表，例如把“l”误识别成“I”这类情况）、统一标点格式。这个清洗层看起来不起眼，但它决定了后续批改体验的下限。

3.2 逐句批改的对齐问题：AI 批改的句子必须和原文一致

逐句批改的返回结果里，模型会给出“错误句子片段”。“对齐”问题是这里最大的工程难点：模型批改时引用的句子片段与用户原文在措辞上不一致，导致前端无法高亮定位。

我当时的做法是：不依赖模型返回的字符串去做精确匹配，而是先按句号、问号、感叹号把用户原文切成句子数组，为每个句子分配一个句子编号，然后让模型在返回结果里带上“句子编号”字段。这样即使模型的引用措辞稍有出入，前端也可以根据编号准确定位到对应句子，再在句内做模糊匹配来高亮错误片段。

这里又要提到 Prompt 设计的一个原则：凡是能让模型输出的结构化字段，绝对不要让它自由发挥。通过规范返回 JSON 格式指定字段，极大的提升了后续处理的稳定性。

3.3 错误分类与弱项追踪的数据设计

批改结果的维度分要能沉淀成用户画像，数据设计上就不能只存一份“批改报告”字符串。我的方案是：批改结果解析后拆成几张表来存储：

• 报告主表：存用户 ID、作文 ID、总分、各维度得分、批改原文、总评建议；
• 错误明细表：每条错误单独一行，包含句子编号、错误类型（语法/词汇/搭配/逻辑/内容）、原文片段、修改建议、是否已读；
• 用户能力表：按用户维度聚合每次批改的维度得分，计算近期均值与趋势。

这个设计让我在后续做“用户弱项雷达图”和“进步曲线”的时候，只需要查询聚合表，不用每次都去解析大段 JSON。错误类型分类也不是只给一个大类，而是细分到“主谓一致”“时态错误”“冠词缺失”“介词搭配”“中式表达”“逻辑跳跃”等二级标签，尽量贴合用户对错误的理解。这样用户在端上看到的不只是一个笼统的“语法错误”，而是能清楚地知道，自己的薄弱环节到底在哪里，更有利于自我提升。

4. 开发当中绕不开的那些坑

4.1 模型会“编造”原文里没有的句子

我第一次测试整篇批改时，发现一个诡异现象：模型的总评里提到了一个很有道理的批评，说原文第三段“论证不够充分，缺少对反方观点的回应”，但我去翻用户原文，第三段根本没有讨论反方观点。这是模型的幻觉问题——AI 在生成评价时，倾向于构造一个“合理的批评”，然后编一个看起来合理的依据，而不是老老实实基于原文点评。

这个坑处理起来比较麻烦。我的应对策略是“原文锚定”：在 Prompt 中明确要求，所有总评中提到的问题必须引用原文句子作为证据，并且不允许在评价中引入原文不存在的内容；同时在用户端，把每一条总评和它引用的句子建立联动，点击总评某一句话，右侧自动定位到对应的原文片段。这个设计相当于把模型的输出和用户原文绑定，幻觉一旦出现，用户能立刻发现，而且产品交互上也变成了“评价可溯源”，信任度反而提升了。

另外，把模型温度参数调低（0.2 左右），也能明显减少无根据的发散评价。温度调高虽然会让评语更“有文采”，但在教育场景里，我们宁可要稳定的、有依据的反馈，也不要“妙笔生花但胡说八道”的评语。

4.2 手写识别差点翻车：识别率测试要从真实场景收集素材

说实话，手写体识别在这个项目里是最难啃的骨头。我早期测试时用的是打印体作文，识别率很高，很有信心。后来在真实用户内测里才发现，很多人提交的是手写作文，尤其是有的人字迹连笔、行距不齐、还带涂改。通用 OCR 在这种输入上的表现，用“惨不忍睹”来形容不为过。

后来我专门收集了一批手写作文样本，包括字体工整的、潦草的、铅笔写的、带了轻微涂改的，做了一轮针对性的预处理调优。例如：

• 识别前先把图像做去噪；
• 行高检测时设定一个合理的阈值区间，排除涂改痕迹和页眉页脚的干扰；
• 针对“手写体中的常见混淆对”（如 rn 和 m、cl 和 d、il 和 u）做后处理替换。

调优后手写体的整句正确率从最初的不到 60% 提升到 85% 左右，仍然无法和印刷体比，但至少能支撑批改流程。这里给的建议是：做 OCR 相关功能，开发阶段就要开始收集目标场景的真实样本，识别效果要以真实样本为准，不要用规整测试图来自我安慰。

4.3 批改任务的大小与并发：既要控制成本，也要控制延迟

一次完整批改调用三次模型接口，如果所有用户都同时使用，并发量和成本压力都不小。我在架构上做了两个优化：

第一，批改请求依托消息队列做异步化处理，用户提交作文后不用一直等结果，可以先收到“批改中”的提示，模型调用完成后再通过推送通知用户查看结果。第二，在服务层加了一个简单的响应缓存，相同文本相近参数的请求直接命中缓存结果，这样可以避免重复花费模型调用的费用。尤其对于“同一篇作文反复查看批改报告”这种情况，缓存效果非常明显。

在模型参数上，我也做了一些成本控制：批改模式下给最大输出长度设一个合理上限，不要把上下文窗口全部用完；对于比较短的作文，自动精简 Prompt 里的示例数量，减少不必要的 token 消耗。这些小优化看起来不起眼，但当你的用户量上来之后，节省下来的费用是很可观的。

4.4 用户输入的不确定性：不是每篇作文都是“干净”的

用户实际提交的作文，可能是从纸质书上拍下来的，可能是从网页复制粘贴的，也可能是 OCR 识别后直接提交的。文本里可能带着页眉页脚、出版信息、多栏排版、乱码字符。如果不做输入清洗，模型会把这些噪声当成正文来批改，结果自然是一塌糊涂。

我在服务层加了一个输入预处理流程：去 HTML 标签、去 URL 和邮箱、合并多余空白、识别并删除疑似页眉页脚的行、把全角标点转换成半角。然后设置一个“有效文本长度”检查：如果清洗后的文本少于一定字数（比如 50 词），直接提示用户“未能识别到足够多的作文内容，请重新拍照或粘贴。”这一步有效拦截了相当一部分无效的批改请求，既省了成本，又避免了用户被离谱批改结果劝退。

5. 高频问题排查与迭代复盘

5.1 线上反馈质量问题：怎么判断是模型不行还是提示词不行

实际运营中我接到的用户反馈，有一类特别典型：“AI 批改有的地方说得对，有的地方明显是误判，比如把正确的句子当成错误的改。”这类反馈如果不细查，很容易归咎于“模型能力不够”，但我在逐个分析日志后发现，大部分误判的原因是提示词中的错误类型定义不够清晰，模型对“什么是错误”的标准理解不一致。

比如，有些所谓“错误批改”其实是把用户一个可接受但非最优的表达，当成硬性错误强行修改。模型分不清“错的”和“不够好”的边界。后来我在提示词里专门加了一个层级说明：只有存在明确语法错误或语义不成立时必须标记为“错误”；表达不够地道但语法正确、语义清楚的，归为“建议优化”而非“错误”。这个改动显著降低了误报率。这个经验是，大模型的输出质量问题，第一步永远先检查 Prompt 引导是否足够明确，不要轻易换模型或者加规则，后者成本高且不一定有效。

我把开发中遇到的高频问题整理成了如下速查表：

5.2 数据安全与体验之间的平衡

写作内容是非常私人的数据。用户愿意把自己的作文传上来，是基于信任。所以在产品设计上，隐私相关的问题必须前置考虑：传输过程要加密，存储时做脱敏与访问控制，批改结果默认仅用户本人可见，分享功能如果需要开放，必须先让用户主动确认具体分享范围。

在体验的细节上，我的做法是：批改报告生成后默认保留 30 天，用户可以选择永久保存到自己的本地空间；如果要删除账号，所有批改记录一并清除。这些细节虽然不直接产生功能价值，但它在用户信任层面特别重要。做教育和工具类产品，用户体验的边界不只是操作流畅度，还包括数据安全感，后者长期来看决定产品的口碑天花板。

5.3 内测阶段的观察：真实用户使用路径与你的设计路径往往不一样

功能上线后，我组织了二三十个目标用户做内测，观察他们使用产品的方式。一个发现让我很意外：很多用户并不是“写完再批改”这个预期路径，而是先随机找一篇自带例文，不写任何内容，直接点批改看看效果。如果批改反馈看起来“很值”，他们才愿意认真写一篇文章来获得反馈。

这说明一个道理：这类产品的首批用户需要先被“反馈质量”打动，才会进入“练习闭环”。所以新用户引导流程上，我后来加了一个“体验批改样本”的入口，内置一篇带典型问题的作文供新用户快速体验批改效果，让用户在还没有写作文压力的情况下，先感知到 AI 批改的能力水位。从内测数据看，这个入口对用户留存有正向影响。

6. 成本控制与后续扩展思路

6.1 单次批改成本压不下来怎么办

聊一点实际的经济账。一次三链路并行批改，按中等级别模型的定价水平，单次要消耗 6000~9000 tokens 左右，成本在同类产品里并不算低。前期用户量不大的时候还能接受，但这个成本模型必须要提前考虑。我有几个方向可以参考：

• 策略一：按用户类型分阶梯。免费用户每天限制 1 次深度批改，深度批改走完整三链路；付费用户不限额。
• 策略二：对于轻量需求（比如只想知道这篇文章大概多少分），做一个“快速评分”通道，只调用一次循环链路，成本降低到原来的三分之一左右。
• 策略三：高频重复请求的缓存，配合文本局部哈希，精准命中同一篇作文重复批改的场景。

从长期看，模型推理成本整体会逐步下降，但产品设计上仍然要注意别滥用模型能力。能用规则解决的问题（比如标点检查）就别用模型；能用轻量模型解决的场景别总是用重量级模型。做一个功能之前先问一句：这个能力真的需要大模型才能完成吗？想清楚这一层，你就不会在和成本较劲的时候束手束脚。

6.2 后续产品功能扩展的方向

基于目前这个项目的沉淀，后续如果要持续迭代，我重点关注的方向有几个：

自定义批改标准。目前批改反馈是通用的学术写作视角，但不同用户需求差异很大（雅思小作文的图表描述和托福独立写作的论证逻辑，关注点完全不同）。让用户选择“备考类型”，模型按对应的评分标准来批改，反馈的针对性会显著提升。

同主题重写对比。记录用户修改前后的两个版本，通过版本对比让用户直观看到自己的问题是否真的改掉了。这个功能对学习闭环的价值非常大，而且技术上完全可以在现有数据基础上追加。

口语批改的延伸。写作和口语在表达层面有很多共通之处，尤其是在逻辑组织、用词多样性这些维度。如果能把“读自己的作文并录音”的功能加上，就相当于把同一套批改能力迁移到口语表达反馈上，产品天花板会被拉得更高。

这些都是基于当前能力自然生长出来的方向。但在此之前，先把“一次写作批改的反馈质量”打磨到绝大多数用户觉得“值”——这是所有扩展的前提。

这个项目做完之后，我个人的一个体会是：AI 教育类产品的门槛不在模型调用，而在“你如何把教学环节里那些隐性知识显性化为工程规则”。模型可能什么都会一点，但如果你不理解写作教学本身，你就无法设计出能让用户进步的反馈体验。哪怕是“错误要分成语法错误和优化建议两层”，这个看起来不起眼的产品决策，背后都是对用户真实学习需求的判断。技术只是实现的手段，真正值钱的是你对场景的理解深度。