企业官网建设流程全解析

写到日报我就头疼。白天代码敲得飞起，到下班写“今日工作总结”时，脑子里一片空白，只能对着 git log 一条条翻，再手动拼成一段能交差的话。说辛苦吧也不是辛苦，就是烦，而且浪费时间。所以我干脆写了一个小工具：用 Python 把当天的开发痕迹、待办事项、会议记录收集起来，再丢给 AI 大模型接口做自然语言整理，自动生成一篇像人写的日报。项目不大，但“从 0 到 1 ”的每一步都值得记录，这篇文章就把我的设计思路、踩坑过程和核心代码都摊开讲，源码我也会开放。

1. 日报自动化的痛点和整体设计思路

1.1 日报的高频场景与隐蔽成本

日报这件事，在不同团队里的意义差别很大。有的团队只看“今天做了几个需求、修了几个 bug”，有的团队领导会认真看你每天的文字总结，用来做周报汇总、绩效回顾、项目风险判断。不管哪种，日报都承担着“信息同步”的核心职责。问题在于，写日报这个动作往往发生在下班前最疲惫的时间段，人的记忆不可靠，今天改过哪几个文件、和谁对过结论、帮哪个同事处理了线上问题，很容易漏掉。漏掉之后，要么日报里出现“处理日常工作”这种废话，要么第二天补写时花更多时间回忆，这就是一种隐蔽的时间成本，团队越大越明显。

另一个被低估的问题是日报的“低水平重复”。大部分人每天的工作都能拆成几类：开发、沟通、排查、复盘。如果你发现自己连续三周的日报都是“修复 XX 问题”“跟进 XX 需求”，那日报就没起到记录价值、复盘价值的作用。但我把日报当成一个数据整理问题来看待之后，思路就变了：日报不是靠脑子回忆出来的，而是靠数据记录、归纳、呈现出来的。既然数据都在系统里，完全可以让程序把数据拽出来，再交给 AI 做表达层的加工。

1.2 为什么用 Python + AI，而不是纯模板

我最早想过用纯模板生成日报。比如把 git 提交记录按时间排出来，塞进一个固定模板，替换掉日期和提交信息。这个方案的优点是稳定、零成本、不依赖外部接口，缺点也是致命的：生成的日报机械得像机器翻译，同一个项目下十条提交信息格式还各不相同，“fix bug”和“修复了缓存导致商品价格显示异常的问题”这两种表达生硬地混在一起，领导一眼就知道是模板生成的。

AI 的价值在于把结构化的数据转译成“人话”。同样是提交记录，AI 能理解“fix: 修复商品价格缓存未失效的问题”意味着“修复了一个线上问题，原因是缓存策略不合理，涉及价格展示链路”，并且把它转写成完整的句子。更关键的是，AI 能挑重点。如果某天产生了 20 条提交，其中 15 条都是同一个需求的拆分子任务，AI 会归纳成“完成 XX 需求开发”，而不是逐条罗列。这种归纳能力，传统规则很难做到自然。

选 Python 是因为它处理文本和调接口都足够顺手，第三方库生态成熟，写一个“小工具”类型的项目不需要绕路。代码量控制在千行左右，想加数据源、换输出格式、接定时任务，都非常迅速。项目整体设计成一条流水线：数据源采集、内容清洗、AI 生成、格式化输出。每个环节尽量独立，方便单独调试。

1.3 整体架构与数据流转

我把它做成一个命令行工具，方便在服务器上配合计划任务运行。核心流程如下：

1. 根据日期范围收集数据。开发者的数据主要来自 git 提交日志，也可以读取一个 JSON 格式的待办文件；产品、运营可以把当天整理的笔记、表格导出成 Markdown 或 JSON 放在指定目录里，程序统一读取。
2. 对收集到的原始文本做清洗。去掉不需要的 commit hash、修掉乱码、把英语关键词翻译成中文提示词，这一步直接影响 AI 的输出质量。
3. 组装提示词。把清洗后的数据和一段精心设计的“日报写作要求”拼起来，发给大模型 API。
4. 拿到 AI 返回的草稿，再套一层本地模板，输出成 Markdown 文件，或者进一步转成 Word、邮件正文。
5. 如果想做到完全自动化，就把命令挂到计划任务里，每天 17:50 执行一次，生成文件后放到指定目录。

数据流转是“原始记录 -> 提炼后的半结构化文本 -> 自然语言草稿 -> 格式化成品”。这个设计让我在调试时能做到每一段单独验证：今天 AI 生成得不好，问题一定出在“输入数据”或者“提示词”，不会牵扯到采集逻辑；反过来，如果采集的数据不对，就算提示词写得再好也是白搭。

2. 数据收集与清洗：日报能不能用，七成取决于这一步

2.1 不同岗位喂给 AI 的“原材料”应该是什么

我在设计时没有只盯开发者，因为团队里除了程序员，还有产品、测试、运维。他们的日报素材来源完全不同。我整理了一张映射关系表，这张表也直接决定了我项目里设计了哪几种数据源。

我先实现了三种输入：git 提交日志、JSON 待办清单、Markdown 备忘录。其中 Markdown 备忘录是最灵活的一种，任何人都可以把“今天开了个会，结论是……”写进一个文件，程序读取后交给 AI。没有技术背景的人也能用。

2.2 用 git log 精确提取当天的提交信息

做开发的人都知道，git log 是提取提交记录的首选。但直接执行 git log 会把仓库所有历史都打出来，还需要限定日期和作者。我之前在某次项目里踩过坑：脚本写得太简单，没加 author 过滤，结果把同事提交的代码全算到自己日报里，尴尬过一次之后就长记性了。

下面这一段是提取当天提交信息的核心逻辑：

import subprocess from datetime import datetime, timedelta def get_git_log(date: str, author: str = None) -> str: since = f"{date} 00:00:00" until = f"{date} 23:59:59" cmd = [ "git", "log", "--since", since, "--until", until, "--pretty=format:%H%x09%an%x09%ad%x09%s", "--date=format:%Y-%m-%d %H:%M:%S" ] if author: cmd += ["--author", author] result = subprocess.run(cmd, capture_output=True, text=True, encoding="utf-8") return result.stdout.strip()

代码用了%H拿完整 commit hash，用%an拿作者名，%ad格式化提交时间，%s是提交标题。拿到之后我会再做一次清洗：保留标题和作者名，把 hash 去掉。因为 AI 不需要知道 hash，它只需要知道“谁、在什么时间、做了什么”。

清洗时还会忽略一些明显无意义的提交，比如Merge branch 'xxx'、update README、fix typo。这些噪声如果你不提前过滤，AI 会很认真地写进日报：“更新了 README 文档”，看起来工作量很大，其实毫无价值。

2.3 待办、备忘录与自定义输入的数据格式

为了解决 git 记录覆盖不到的场景，我设计了一个统一的 JSON 输入格式。用户把当天比较重要的工作写进去，程序读取后作为数据源之一。示例格式如下：

{ "date": "2025-01-06", "todos": [ {"time": "09:30", "done": true, "content": "确认订单导出功能的需求边界，输出结论到群文档"}, {"time": "14:00", "done": true, "content": "排查用户反馈的导出失败问题，定位到内存溢出"}, {"time": "16:30", "done": false, "content": "整理周报素材，补充数据看板截图"} ], "notes": [ "下午与测试对齐 XX 版本回归范围，新增 3 个用例", "收到线上告警 1 次，确认是偶发网络抖动，已恢复" ] }

这里有个细节：done: false的待办，我会在清洗阶段单独打一个标记，让 AI 知道“这里有未完成项”，它生成日报时可能会写“下周需要继续跟进 XX”，比掩埋信息要真实得多。开发者也完全可以把这个 JSON 文件做成一个简单的命令行交互式输入，下班前花一分钟填两行，成本可控。

清洗阶段还要做一件事：把内容长度做限制。如果某一天提交记录有五十条，全部塞给 AI 不仅 token 超标，AI 反而会抓不住重点。我会对提交记录做“按关键字合并”：把包含 commit 头feat、fix、refactor的记录分别聚合，每个类别只保留前三到五条最重要的。这样 AI 拿到手的，永远是一份“容量适中且有结构”的素材。

3. AI 生成日报的核心：提示词设计与参数调优

3.1 一套经过反复打磨的提示词模板

AI 部分最关键的，不是用哪个大模型，而是你给它的“任务说明”是否足够准确。一开始我用的提示词非常短：“请根据以下数据生成日报”，结果 AI 自由发挥严重，把根本没做过的事写得跟真的一样，比如“完成了订单模块重构，提升系统性能 30%”，这种话交上去会被领导质疑到死。

后来我把提示词拆成三段：角色设定、写作要求、输入数据。角色设定让 AI 明白它是“一个帮你把琐碎工作记录转写成正式日报的助理”，不是“主动总结人”的角色。写作要求逐条列死，防止幻觉。实际模板类似这样：

你是一名工作日报助理。请根据提供的原始工作记录，写一篇适合发给团队负责人的中文日报。 要求： 1. 只能基于给定内容改写和归纳，禁止编造任何不存在的任务、数字和结果。 2. 使用第一人称“我”来表达。 3. 正文分三部分：今日完成、问题与风险、明日计划。没有的内容可以省略，但不得虚构。 4. 语言简洁，避免空话套话。不要使用“取得显著成果”“高效推进”这类没有信息量的词。 5. 每条产出尽量包含“动作 + 对象 + 结果/原因”，比如“修复了导出功能内存占用过高的问题，异常率从 5% 降到 1%”。 原始工作记录： {清洗后的数据}

这个模板的每一条要求都有针对性。“只能基于给定内容”是为了防幻觉；“使用第一人称”是为了更像人写；“动作 + 对象 + 结果”是为了让日报有信息量，而不是流水账。实际生成的日报，AI 会把结构混乱的提交记录整理成通顺的句子。我分享一个简化版的调用片段，用的是通用的 HTTP 请求方式，具体接口字段以你实际使用的大模型服务为准：

import requests def generate_daily_report(material: str, api_key: str, endpoint: str) -> str: prompt = f"""你是一名工作日报助理。请根据提供的原始工作记录，写一篇适合发给团队负责人的中文日报。 要求： 1. 只能基于给定内容改写和归纳，禁止编造任何不存在的任务、数字和结果。 2. 使用第一人称“我”来表达。 3. 正文分三部分：今日完成、问题与风险、明日计划。没有的内容可以省略，但不得虚构。 4. 语言简洁，避免空话套话。 5. 每条产出尽量包含“动作 + 对象 + 结果/原因”。 原始工作记录： {material} """ resp = requests.post( endpoint, headers={"Authorization": f"Bearer {api_key}"}, json={ "messages": [ {"role": "user", "content": prompt} ], "temperature": 0.3, "max_tokens": 800 }, timeout=30 ) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"]

3.2 温度、长度与重试策略

AI 接口不是绝对的稳定，配置参数直接决定了输出质量。先说温度。日报生成是个确定性要求比较高的场景，温度我固定在 0.2 到 0.4 之间。温度接近 0，AI 会更保守，不太会用华丽词藻；温度太高，它可能给你写出“今天我像一只勤劳的代码蜜蜂”，这种内容交不了差。0.3 是我试下来最平衡的值。

max_tokens通常设 800 到 1000 就足够。如果数据源特别杂，比如有几十条任务和多个备忘录，token 长度要相应往上调，否则输出会戛然而止，日报只写到“今日完成”一半就结束了。我还会在程序里对 AI 的返回结果做一个后置断言：如果文本长度少于设定阈值，说明大概率没生成完整，直接重试一次。

重试比很多人想的更重要。大模型接口偶尔会因为负载原因返回 5xx 错误或者超时。我在项目里加了一个简单的重试函数：最多尝试三次，第一次失败等 1 秒，第二次失败等 3 秒，第三次失败等 9 秒。这个“指数退避”策略可以避免服务还没恢复时频繁打接口。如果你把日报都依赖定时任务来跑，建议给程序做一个“失败之后保留原始数据”的兜底逻辑，至少当天数据不能丢。

3.3 让 AI 生成的日报看不出“AI 味”

我见到很多人抱怨“AI 生成的日报一看就是 AI 写的”，其实问题不在 AI，在于提示词没把风格说清楚。AI 生成的典型通病有两个：一是喜欢堆“积极正面”的空词，二是喜欢把简单的事情说复杂。

我需要让提示词里明确写“禁止使用空话套话”，甚至可以在模板里列举反例，比如“高效推进”“通力配合”“显著提升”都是禁用词。还有一个很有效的技巧：在提示词里加一个“改写风格示例”，给 AI 一两个参考例句。比如原记录是“修复导出失败问题”，期望改写成“修复了订单导出偶发失败的问题，定位为内存未释放，已补充回归用例”。

另外一个更“坏”的技巧是后处理。AI 生成完，我用一段简单的正则脚本，把“成功”“圆满完成”“攻坚克难”这类词替换成更中性的表达。有人说这不是多此一举吗？其实不是。AI 的输出带有明显的“完成时态”和“功劳语气”，但人的日报往往是“做了什么 + 做到什么程度 + 下一步怎么办”，看似细微的替换，能让文本显得克制很多。

4. 完整实现过程：目录结构、核心代码与常见配置

4.1 项目目录与依赖清单

整个小工具我控制在了一个比较清晰的项目结构里，方便以后加数据源、换模板。

auto-daily/ ├── main.py # 入口，解析参数，编排流程 ├── config.yaml # 全局配置：日期、作者、API 地址等 ├── collectors/ │ ├── __init__.py │ ├── git_collector.py # 收集 git 提交日志 │ └── json_collector.py # 读取待办 JSON、备忘录 Markdown ├── ai_generator.py # 组装提示词、调用大模型接口 ├── formatter.py # 把 AI 结果渲染成 Markdown / 邮件正文 ├── templates/ │ └── daily_template.md # 日报排版模板 ├── output/ # 生成结果保存目录 └── requirements.txt

依赖很少：requests用于调 AI 接口，pyyaml读取配置，python-dateutil处理日期窗口。如果你想输出 Word，可以额外引入一个 docx 处理库，但这不在最小化版本里。

config.yaml长这样：

date: auto # auto 表示今天，也可以指定 yyyy-mm-dd author: "" # 留空则不过滤 git 作者 repository: . # git 仓库路径 output_dir: output ai: endpoint: "https://your-api-endpoint/v1/chat/completions" api_key_env: "DAILY_AI_API_KEY" temperature: 0.3 max_tokens: 800

我把 API Key 放在环境变量DAILY_AI_API_KEY里，而不是写到 YAML，避免提交代码时把密钥带出去。这一点，初学者特别容易忽略，等代码仓库被意外分享出来才发现密钥已经泄露了，很麻烦。

4.2 入口编排与实现逻辑

入口main.py的逻辑很简单：读配置、收集数据、清洗、调 AI、格式化、写文件。我不会把复杂的业务逻辑堆在入口，而是每个环节都封装成独立函数，便于单测和替换。

def main(): cfg = load_config("config.yaml") date = cfg["date"] if cfg["date"] != "auto" else date.today().isoformat() git_material = "" if os.path.exists(cfg["repository"]): git_material = get_git_log(date, cfg.get("author")) todo_material = """ """ todo_file = Path(cfg["output_dir"]).parent / "todos" / f"{date}.json" if todo_file.exists(): todo_material = load_json_file(todo_file) material = clean_and_merge(git_material, todo_material) if not material.strip(): print("没有收集到任何数据，跳过生成。") return report = generate_daily_report(material, ...) output_path = save_markdown(report, date, cfg["output_dir"]) print(f"日报已生成：{output_path}")

这里值得注意的一点：如果当天没有任何提交、也没有待办记录，程序应该直接退出而不是继续请求 AI。因为空素材生成出来的日报大概率是胡说八道，浪费 token 不说，还可能伪造出一些工作任务来。我加了条件判断，没数据就跳，绝不硬编。

4.3 格式化输出与定时任务配置

生成出来的 Markdown 文件是最通用的中间格式，既可以打开直接看，也可以转成 Word 发送。我会在daily_template.md里放一个排版骨架，比如日期、天气（其实不需要）、今日完成列表、问题和风险、明日计划。AI 生成的正文填进去，整体观感就比纯文本好很多。

如果你需要发邮件，也很简单。每天定时生成 Markdown 后，再把它转成 HTML 邮件正文，用自带的电子邮件发送库发出去。我并没有在一开始就做邮件功能，因为团队协作里大家接收日报的方式不一样，有人习惯看群文件，有人习惯收邮件，先输出标准化文件，后续再决定分发渠道会更省事。

定时任务我是在 Linux 机器上用 cron 跑的，命令如下：

30 17 * * 1-5 cd /path/to/auto-daily && /usr/bin/python3 main.py --date today >> logs/run.log 2>&1

这条 cron 规则表示每周一到周五的 17:30 执行。日志重定向到logs/run.log，方便排查。改成 Windows 下的计划任务也是一样的逻辑，核心是“给定日期 + 自动生成 + 落盘”。

4.4 源码开放的说明

完整代码我已经整理好并放到了代码仓库，仓库里包含上面说到的所有模块，以及两个示例数据文件。如果只是想快速体验，可以在仓库根目录跑一句：

python main.py --date 2025-01-06

前提是把config.yaml里的大模型接口地址和密钥配置好。如果你所在团队对数据安全要求高，不能调用外部接口，也可以把ai_generator.py里的 HTTP 请求替换成本地模型提供的兼容接口。接口字段基本一致，改动量很小。

5. 开发与使用中踩过的坑，以及排查思路

5.1 AI 编造任务行为怎么治

第一个坑，也是我最初使用 AI 工具时最大的痛点：AI 会把提交信息里隐含的信息脑补成“成果”。比如输入里有“修复了某接口空指针异常”，它可能会写成“完成某接口全面重构，优化响应时间约 30%”。这个行为，提示词里的“禁止编造”能约束一部分，但不会完全消失。

我的解法分三层：

1. 提示词里明确写“只允许归纳，不允许新增细节”。
2. 在数据侧降低信息的模糊度。如果提交信息本身没有“优化性能”“性能提升”这些结论，AI 就没有依据生成这些话。
3. 做一次关键词后置检测。检查生成文本里是否出现“提升 30%”“性能提升”“重构完成”这类高频幻觉词，如果出现且原始数据里没有对应依据，就重新生成一次。

说实话，第三层我加的时候有点“暴力”，但它确实管用。有一次它拦截了“显著提升用户体验”这种屁话，让日报回归到了可信状态。这里我要多说一句：AI 生成内容最怕的不是文章不好看，而是不可信。日报是工作依据，一旦失真，工具本身的可靠性就会受质疑，所以后置校验值得做。

5.2 中文提交信息太碎、语义密度太低

我的提交信息一开始很随意，比如fix、update、wip。这种提交记录喂给 AI，效果非常差，它会想尽办法把“fix”写成“修复了一些已知问题”，本质还是废话。

改进有两个方向。一个是强制性规范提交信息，比如按type(scope): subject的格式写。另一个是在清洗阶段把短信息合并成主题组。举个例子：

feat: 增加导出历史记录按钮 feat: 导出任务状态增加失败重试 fix: 导出文件中文文件名乱码

清洗后，我会聚合成：

完成订单导出功能开发，包括历史记录按钮、失败重试机制；修复文件名乱码问题。

AI 看到的是已经组织好的强语义文本，它做的是润色和排列，而不是从碎片信息里瞎猜。这个习惯后来直接影响了我的各种自动化工具，统一思路是：给 AI 之前，先把数据做“人读预处理”，AI 只是最后一步的表达器。

5.3 接口超时、限流与 Keys 管理

调大模型接口不是每次都能一次成功的。我遇到过 429 限流、超时、返回非 JSON 的异常响应。建议你在程序里统一处理这些异常，不能一崩了之。最好有一个简洁的异常上报，比如把失败信息写入日志，并保留当天的收集结果，下个月再看还能不能重跑。这里有个细节指标可以分享：我把重试逻辑设为 3 次而不是 5 次以上。因为日报生成是下班前后的“低峰期”任务，失败后你可以手动再跑，重试太多次反而会拉长任务时间，耽误定时流程的后续步骤。

Key 的管理，再次强调：永远不要写死在代码里，也不要提交到仓库。用环境变量配合.gitignore忽略配置文件，基本是行业共识。哪怕你只是一个人使用，也要习惯这个规则。

5.4 定时任务中跑出来空日报怎么排查

之前我把命令挂上 cron 之后，发现连续两天生成的日报文件都是空。排查后发现是环境变量问题：cron 执行时的 PATH 和登录终端不一样，它找不到git命令。这是老掉牙的坑但依然经典。

我的排查流程如下：

1. 先手动执行同样的命令，确认能生成。
2. 查看 cron 日志，确认有没有报错。
3. 把 cron 命令里的git全路径换成/usr/bin/git，重新测试。
4. 确认脚本里有没有依赖相对路径的地方，把cd到项目目录保证路径正确。

如果你用的系统是 Windows 计划任务，还要注意 Python 解释器的绝对路径，以及工作目录的设置。很多定时任务跑空，都和“目录不对”“命令找不到”有关。

5.5 让工具真正被团队接受的经验

工具做出来不难，难的是同事愿意每天给你“喂数据”。我发现如果只靠 git 提交记录，日报里只有代码开发，测试同事和产品同事根本没法参与，因为他们不写代码。后来我做了两件事：

第一，把输入做得足够简单。不要求大家学命令行，直接把备忘录 JSON 放到特定目录，程序自动读取。如果连 JSON 都嫌麻烦，那就留一个notes.md，把当天要点写进去即可。

第二，允许 AI 生成后人工微调。我不会让工具自动发送邮件，而是生成一个 Markdown 文件，让用户自己改、自己发。把 AI 定位成草稿生成器，而不是最终信使，信任感会高很多。这一步，是工具能不能长期用下去的隐藏关键。

6. 扩展空间：从自动写日报到自动写周报、月报与更多可能性

6.1 用同一套数据源生成周报和月报

日报生成之后，很多人会自然地想到周报。实际上做好一周的数据聚合，周报的生成可以直接复用同一条链路。差别只在时间窗口：把“当天 00:00 到 23:59 ”改成“本周一 00:00 到周日 23:59”，然后让 AI 的提示词从“写一篇今日日报”变成“从以下一周数据中提炼本周重点，归纳成三条主要成绩和一项风险”。

同样的数据源，不需要额外开发采集逻辑，只是给git_collector传一个日期范围参数。月报则更关注指标和趋势，比如本月提交数、需求完成率、处理事故数。写 AI 提示词时，要让它多使用数据汇总。这个扩展只需要一两个小时就能完成，是我觉得性价比最高的后续动作。

6.2 适配不同角色：销售、客服、运维

如果团队里有销售，日报素材可能是 CRM 客户跟进记录、订单状态变化、关键商务会议。客服的素材来自工单数量、平均响应时长。运维的是变更、告警、工单。本质上任何有“结构化工作痕迹”的岗位都可以接入。

我计划后续把数据源做成插件式接口，每次新增岗位只需要写一个 hour 的类，返回统一格式的数据。目前这个版本只覆盖了开发者场景，但在数据结构设计上已经为扩展留好了口子，比如统一使用{"time", "done", "content"}列表描述任务。

6.3 本地化部署与隐私考量

日报内容里难免涉及业务细节和数据信息。有些团队不愿意把数据送到外部 API，这时候可以考虑本地部署一个小参数模型来执行生成任务。生成质量可能比大模型 API 差一些，但胜在数据不出内网。

如果走本地部署，需要注意模型对中文长文本的处理能力。我当时测试结果表明，很多 7B 级别的本地模型在“单条转写”上不错，但“从几十条提交里提炼重点”的结构化理解能力仍有限，提示词不能和云端超大模型用同一套。这个方向适合对隐私极度敏感的团队去尝试，但对绝大多数普通开发者和个人用户来说，直接使用云 API 加上下文限制已经足够。

6.4 后续我很想做的几个增强

日报只解决了一天一次性输出。接下来我想把同一份数据自动归档，按月做一个“工作回溯”，在月底复盘时能清晰看到这个月完整做过哪些事，哪些是高频工作，哪些是临时打断项。还可以接入团队即时通讯的机器人群，每天定时推送日报提醒。这些扩展都不是核心，但它们会把“写日报”这个工具变成一个轻量级的工作管理入口，这是我期待的方向。

我自己实际连续用了三周之后，最大的感受是“日报终于不用从零开始写了”。每天下班前，我只需花半分钟看一遍 AI 生成的草稿，改掉一两个语气词，补充一句今天没被记录但比较重要的沟通事项，然后提交。这半分钟就是我认为这套工具最健康的用法：人做判断，AI 做整理，而不是让 AI 全权代劳。如果你也想做个类似的东西，我建议你先从最笨的方法开始，把 git 提交记录和待办数据收集起来，写一个简单版本的提示词，跑通全流程，再慢慢打磨表达效果。踩坑本身也是这类项目最上瘾的部分，祝你也写得顺手。