GLM-OCR辅助代码开发解析技术文档自动生成函数注释作为一名写了十几年代码的程序员我太懂那种感觉了接手一个新项目或者翻看自己几个月前写的代码面对着一堆没有注释或者注释寥寥无几的函数那种迷茫和烦躁。更常见的是技术设计文档、API说明截图、甚至手写的架构草图和实际的代码是“两张皮”文档归文档代码归代码时间一长谁都对不上号。今天我想跟你分享一个我自己在用的、能显著提升代码可维护性和开发效率的“土办法”。它不是什么复杂的架构设计而是巧妙地结合了两个现成的AI工具GLM-OCR用于文字识别和AI编程助手用于代码生成把散落在各处的技术文档“变”成规整的函数注释和测试骨架。1. 这个场景到底解决了什么问题想象一下这些日常开发中的典型场景场景一接手遗留代码。你拿到一个没有文档的旧项目唯一能找到的是一份陈年的PDF设计文档或几张模糊的会议白板照片。你需要理解每个模块的功能然后给关键函数补上注释。场景二开发联调对接。后端同事扔给你一个Swagger UI的截图上面有接口字段说明。你需要根据这些信息在代码里写对应的数据模型DTO和接口调用函数并加上详细的字段注释。场景三个人知识管理。你在笔记本上手绘了某个复杂算法的流程图或者在备忘录里用文字描述了一段业务逻辑。过几周需要实现它时你得先“翻译”这些非结构化的笔记再开始编码。传统做法是人眼阅读文档或图片 - 大脑理解 - 手动在代码编辑器中输入注释。这个过程枯燥、易错而且当文档量大的时候极其耗时。而我们想做的是构建一个自动化的小流程让机器去“看”文档提取文字再让AI去“理解”文字生成结构化的代码注释。这就像给程序员配了一个专注处理文档的“实习生”。2. 工具组合与工作流设计整个方案的核心是两个环节信息提取和信息转化。我们不需要从头造轮子用现成的工具搭积木就行。2.1 核心工具选择GLM-OCR信息提取端这是第一步的关键。我们需要一个强大的OCR光学字符识别工具把图片、PDF里的文字准确地“抠”出来。GLM-OCR在这方面表现不错特别是对中文、英文混合的文档以及一些不太规整的排版比如截图有较好的识别率。你可以在其提供的API或开源模型基础上进行调用。AI编程助手信息转化端这是第二步的大脑。我们需要一个能理解自然语言描述并能按照指定格式生成代码或注释的AI。比如一些主流的、支持代码生成的AI大模型。它的任务是把OCR提取的、可能有些杂乱的自然语言文本重新组织成规范的函数注释如Python的docstring、Java的Javadoc或单元测试框架。2.2 自动化工作流拆解整个流程可以很简单用脚本串起来# 这是一个概念性的伪代码流程展示核心步骤 import ocr_tool # 假设的OCR工具包 import ai_coder # 假设的AI编程助手调用客户端 def auto_generate_comment_from_doc(image_path, code_function_name): 从技术文档图片中自动生成函数注释。 Args: image_path (str): 技术文档截图或图片的路径。 code_function_name (str): 需要生成注释的函数名。 Returns: str: 生成的规范化函数注释字符串。 # 第一步使用GLM-OCR识别图片中的文字 print(f正在识别图片: {image_path}) extracted_text ocr_tool.recognize(image_path) print(f识别出的原始文本:\n---\n{extracted_text}\n---) # 第二步清洗和预处理OCR文本如去除无关字符合并断行 cleaned_text preprocess_ocr_text(extracted_text) # 第三步构造Prompt调用AI编程助手 prompt f 你是一个资深的程序员。请根据以下关于函数 {code_function_name} 的技术描述 生成一个完整、规范的函数注释Docstring。 技术描述可能来自文档或截图 {cleaned_text} 请生成适用于Python语言的docstring包含Args、Returns、Raises如果有等部分。 如果描述中涉及参数请仔细提取并归类。 只输出最终的注释内容不要有其他解释。 # 调用AI模型 generated_comment ai_coder.generate_code(prompt, modelglm-4) return generated_comment # 假设的预处理函数 def preprocess_ocr_text(raw_text): # 这里可以做一些简单的文本清洗比如合并因换行被切断的单词/参数 # 这是一个简化示例 lines raw_text.split(\n) cleaned_lines [line.strip() for line in lines if line.strip()] return .join(cleaned_lines) # 或者根据逻辑保持段落结构 # 使用示例 if __name__ __main__: comment auto_generate_comment_from_doc(api_spec_screenshot.png, calculate_user_score) print(生成的函数注释) print(comment)这个脚本勾勒出了核心思路输入图片和函数名输出格式化注释。你可以把它集成到你的IDE如VSCode的某个任务、构建流程或者做成一个简单的本地GUI工具。3. 实战应用从API截图到完整注释光说理论有点虚我们来看一个具体的、完整的例子。假设场景你需要实现一个叫calculate_monthly_payment的函数而产品经理只给了一张模糊的、包含了计算公式的会议纪要截图。第一步原始输入OCR识别前你有一张这样的图片上面写着函数计算月供 (calculate_monthly_payment) 参数 - 贷款总额 (principal): 数字单位元 - 年利率 (annual_rate): 百分比如5.5表示5.5% - 贷款年限 (years): 整数 公式月供 [本金 * 月利率 * (1月利率)^还款月数] / [(1月利率)^还款月数 - 1] 其中月利率 年利率 / 12 / 100 返回浮点数保留两位小数 错误如果年限0抛出ValueError第二步经过GLM-OCR识别和简单清洗后得到的文本OCR可能不是百分百完美但核心信息已提取函数 计算月供 (calculate_monthly_payment) 参数 贷款总额 (principal) 数字 单位元 年利率 (annual_rate) 百分比 如5.5表示5.5% 贷款年限 (years) 整数 公式 月供 [本金*月利率*(1月利率)^还款月数]/[(1月利率)^还款月数-1] 其中月利率年利率/12/100 返回 浮点数 保留两位小数 错误 如果年限0 抛出ValueError第三步构造Prompt调用AI编程助手我们将上述文本和函数名填入一个精心设计的Prompt模板请根据以下技术描述为函数 calculate_monthly_payment 生成一个Python风格的完整docstring。 技术描述函数 计算月供 (calculate_monthly_payment) 参数 贷款总额 (principal) 数字 单位元 年利率 (annual_rate) 百分比 如5.5表示5.5% 贷款年限 (years) 整数 公式 月供 [本金月利率(1月利率)^还款月数]/[(1月利率)^还款月数-1] 其中月利率年利率/12/100 返回 浮点数 保留两位小数 错误 如果年限0 抛出ValueError要求 1. 生成标准的Google风格docstring。 2. 清晰列出参数Args、返回值Returns和可能抛出的异常Raises。 3. 在注释中解释清楚计算公式。 4. 只输出docstring内容。第四步AI生成的最终结果def calculate_monthly_payment(principal: float, annual_rate: float, years: int) - float: 根据等额本息法计算贷款的月供金额。 计算公式 月供 [本金 * 月利率 * (1 月利率)^还款月数] / [(1 月利率)^还款月数 - 1] 其中月利率 年利率 / 12 / 100 Args: principal: 贷款本金总额单位为元。 annual_rate: 年利率单位为百分比。例如5.5 表示 5.5%。 years: 贷款年限必须为正整数。 Returns: 计算出的月供金额为浮点数通常建议保留两位小数。 Raises: ValueError: 如果贷款年限 years 小于或等于 0。 Example: calculate_monthly_payment(1000000, 5.5, 30) 5677.89 # 函数实现代码将放在这里... pass看从一个简单的截图我们几乎自动化地得到了一个非常专业、清晰的函数注释。这比你手动敲键盘要快得多而且格式统一规范。4. 扩展玩法不止于注释这个“OCR AI”的思路非常灵活你可以根据需求扩展出更多提升效率的场景自动生成单元测试骨架把函数的功能描述丢给AI让它生成pytest或unittest格式的测试用例框架你只需要填充具体的测试值。Prompt示例“根据以下函数描述生成3个典型的pytest测试用例包括正常情况和异常边界情况。函数描述[粘贴OCR提取的文本]”从UI草图生成数据模型识别UI设计稿或原型图上的表单字段说明自动生成对应的前端TypeScript接口或后端Java实体类。维护代码与文档同步当设计文档更新后重新运行脚本可以快速检查现有代码注释是否需要更新甚至给出更新建议。处理手写笔记对于纸上手绘的架构图旁的文字说明识别后生成模块或类的初始化文档。5. 一些实践建议与注意事项在实际使用中有几个小点能让你用得更顺手OCR质量是关键GLM-OCR效果不错但如果图片质量太差如高糊、强光反射、奇特字体识别率会下降。尽量提供清晰、正对的文档图片。对于复杂的多栏排版或表格可能需要更专业的OCR服务或进行后处理。Prompt工程是灵魂AI生成的质量很大程度上取决于你的Prompt。要清晰、具体地告诉AI你想要什么格式如Google风格、NumPy风格、包含哪些部分。把OCR提取的文本放在“技术描述”这样的上下文中效果更好。结果需要人工复核目前这还是一个强辅助工具而非全自动流水线。生成的注释和代码骨架一定要由开发者本人进行复核和调整确保其正确性和符合项目规范。从小处开始尝试不要一开始就想把所有文档都自动化。从一个最让你头疼的、注释最少的模块开始或者从每次都要手动敲的数据模型开始体验整个流程再慢慢扩大范围。注意隐私与合规如果处理公司内部的敏感设计文档确保整个流程尤其是调用云端AI API时符合公司的数据安全规定。可以考虑使用本地部署的OCR和AI模型。这套方法用下来最直接的感受就是它把程序员从那种重复性、低创造性的文档搬运工作中解放出来了一部分。虽然需要一些初始的脚本搭建和调试但一旦跑通对于维护大型项目、快速理解遗留代码、或者只是让自己写的代码更友好都有实实在在的帮助。它不是什么银弹但确实是一个能提升幸福感和效率的“杠杆点”。如果你也受困于代码和文档的脱节不妨找个周末下午用GLM-OCR和你的AI编程助手搭一个这样的自动化小工具试试看。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。