尧图网络 高端网站定制 · 原创设计
免费咨询热线
400-888-6620
免费获取方案
ASP.NET OA源码二次开发:审批流引擎改造与实战部署
简介面向.NET开发者的ASPNET自动办公系统OA加审批流完整源码运行环境为VS2008加SQL2005尤其适合需要构建企业级OA解决方案的技术团队也适合个人开发者研究学习。源码采用三层架构覆盖个人事务、日程安排、公司通知、审批流转、审批管理、内部邮件、系统设置等核心模块同时提供审批类别、节点、模板、流程及归档等配置功能集成DsoFramer支持Office 2003至2007在线编辑与修改留痕并配合CKEditor与CKFinder完成公文模板设定标签式界面操作便捷还包含IE中VML绘图模块的使用示例。压缩包内包含总数为2069个文件压缩后大小约8.86MB以js、aspx、cs、html、css等源码文件为主同时包含gif、png、jpg等界面图片资产以及部分dll与配置文件目录结构完整便于部署和二次开发。目前已有1171人学习下载。对需要搭建OA系统的读者而言这套源码提供了可运行的完整业务流程尤其是审批流设计、上传进度条实现和在线编辑集成可作为理解传统.NET办公系统架构与功能的实用参考。1. ASPNET自动办公系统(OA审批流)源码先分清什么是你需要改的我接手过不少“ASPNET自动办公系统(OA审批流)源码”这类工程第一反应都是先问一句这套代码能不能直接跑跑起来之后能不能改成我们自己公司的审批规则。所谓自动办公系统OA核心不是那几个公告、考勤页面而是背后的审批流——请假、报销、用印、合同会签每一张单据怎么从一个节点走到下一个节点。源码的价值就在这里流程引擎、表单挂接、权限体系都是现成的你改的是规则和页面而不是从零写引擎。下面的内容把这类源码从还原数据库到二次开发的完整路径捋一遍适合准备拿一套ASP.NET OA源码做公司内部系统、或者要在这类项目上做毕业设计的人。2. 先认清这套 OA 源码分层架构与审批流核心数据模型拿到源码包先别急着点运行。我不止一次见过同事解压后直接按 F5结果要么数据库连不上要么登录页出来了但流程根本发布不了。原因很简单OA 和普通 CRUD 项目不一样它带了一个内置流程引擎代码分层、表结构、权限都和业务模块耦合在一起。先把骨架摸清后面改起来才不抓瞎。2.1 一套典型 ASP.NET OA 的分层与模块清单市面上能下载到的 ASP.NET OA 源码技术栈高度一致.NET Framework 4.5 左右ASP.NET WebForms 或 MVC 5SQL Server 2008R2 以上ORM 用 EF6 或原生 ADO.NET前端常见 jQuery Layui 或 EasyUI。这是我判断一套源码能不能用的第一个标准如果工程连 .NET Framework 版本和数据库脚本都不标大概率是拼凑项目。分层上基本是三层加一个辅助层。表现层放 .aspx 页面或 MVC 的 Views业务层是 Service 或 BLL 类负责流程流转、权限校验数据访问层是 DAL 或 Repository封装 SQL 或 EF 上下文另外一定有个公用层放加密、日志、分页控件这类基础能力。模块上OA 源码通常可以分成系统管理、办公业务、审批中心三块系统管理管用户、部门、角色、菜单、操作日志、数据字典办公业务是公告、考勤、请假、报销、会议、文件柜审批中心则是流程定义、流程设计器、发起申请、待办、已办、审批记录。我拿到源码会先看数据库脚本里的表数量。一个真正能用的 OA 源码表数量一般在 60 张以上光流程相关就有流程定义、节点定义、路由表、流程实例、任务表、表单关联表这几类。如果只有十几张表那它大概率只是把业务表拼了个页面审批流是写死的——一个节点对应一个 if 分支这种源码只能看不能用。判断方法也简单搜索代码里有没有 Workflow、FlowInstance、Approve 这组关键词出现的次数越多流程引擎越完整。2.2 审批流的数据模型五张核心表决定一切审批流的设计看着复杂落到数据库里就是五个核心概念流程定义、节点、路由、实例、任务。流程定义是一条审批流的头比如“请假审批”节点是每个审批环节比如部门主管审批、总经理审批路由是节点之间怎么跳实例是某一次具体的申请任务是分配给某个人的待办。我一般先把这几张表的关系画出来画完流程引擎的代码就懂了一半。表名字段要点它的作用Flow_DefinitionId, FlowCode, FlowName, Version, Status流程头例如“请假审批”Flow_NodeId, FlowId, NodeName, NodeType, ApproverType, IsCountersign节点NodeType 区分开始/审批/条件/结束Flow_RouteId, FlowId, FromNodeId, ToNodeId, ConditionExpr路由决定下一个节点Flow_InstanceId, FlowId, BusinessKey, Initiator, State, CurrentNodeId一次申请实例Flow_TaskId, InstanceId, NodeId, Assignee, ActionType, Comment, State一个人一条待办ApproverType 是这套模型里最关键的一个枚举常见取值是指定用户、指定角色、指定部门主管、发起人自选。审批流能不能灵活多半看这个字段怎么扩展。State 字段在实例和任务上都有一份实例状态对应用户视角的“审批中/通过/驳回/撤销”任务状态对应每个人的“待办/已办”。用的时候不要混淆审批人点“同意”先改任务状态为已办再去判断整个实例是否应该流转到下一节点。这里要特别说清楚表单数据的关系。业务表单比如请假单和流程是两张皮流程实例只关心流程走到哪一步了不关心请假天数怎么算。两者用 BusinessKey 关联业务表的主键就是 BusinessKey。但条件路由又需要用到业务字段比如“超过 3 天要总监审批”所以流程实例表还会冗余几个字段或者在一张 Form_Data 快照表里放一份字段拷贝。这是 OA 源码里最常见的做法理解这一点就不会在改表时把流程表和业务表搅在一起。2.3 源码阅读顺序先走通主链路再碰设计器源码阅读最怕上来就找流程设计器的前端代码。那里面有拖拽、连线、XML 序列化是整个系统里最复杂的部分但不是核心。我建议的顺序第一找到流程引擎入口类通常是 FlowEngine、WorkflowService 这类名字看它的 Execute 或 Next 方法这是审批动作的统一出口第二跟着一次“发起申请”的动作走页面提交表单、创建流程实例、找到开始节点、按路由生成第一个待办任务第三再看审批动作同意、驳回、转办、撤回分别改哪些表字段。一个判断源码质量的偷懒办法搜索代码里有没有“退回”和“撤回”的实现。很多简化版源码只有同意和驳回没有“退回上一步”和“发起人撤回”实际办公里根本不够用。如果一套源码把退回、撤回、会签都做了流程引擎部分基本可以放心改。再有一个细节是看“重新提交”驳回之后发起人改数据再提是新建一条实例还是复用原实例正规做法是复用原实例并保留审批历史简化版往往新开一条审批记录就断了。读代码时建议把引擎的 Start 和 Transit 两个方法的方法体打印出来对照上面表结构逐行走一遍。我见过最快的上手方式在数据库里手动插一条流程定义和三个节点用调试器单步走一次同意操作看 SQL 查了哪几张表、字段怎么变。走完这一步你对这套源码的理解会超过看十篇文档。3. 本地跑通最小步骤还原数据库、改连接串、走一遍请假审批这一章的目标不是看懂全部代码而是让你双击就能跑起来并且能走通一套流程来验证引擎是活的。源码这种东西跑不通的时候它就是个黑匣子跑通了之后所有问题都变成“改哪里”的问题。3.1 环境准备IIS、.NET Framework、SQL Server 的版本搭配ASP.NET OA 源码最常见的运行环境是Windows Server 2016/2019 或 Windows 10/11 专业版IIS 8.0 以上.NET Framework 4.5/4.6SQL Server 2008R2 到 2019 都行。开发调试用 Visual Studio 2015 以上基本都能打开如果源码是 MVC 5 工程还要确认 NuGet 还原能联网。本地建议直接用 SQL Server Developer 版或 Express LocalDB别一上来就装企业版。开启 IIS 的步骤是控制面板 → 程序和功能 → 启用或关闭 Windows 功能 → 勾选 Internet Information Services再在“应用程序开发功能”里勾选 ASP.NET 4.x。这一步经常有人漏装了 IIS 但没有勾选 ASP.NET结果网站起来了访问 .aspx 页面直接 500。如果源码用 MVC还要确认“HTTP 重定向”和“静态内容”两个子项是勾上的。项目文件里通常有两种数据库交付方式.bak 备份文件和 .sql 脚本。我建议优先用 .bak因为 .sql 脚本常有创建顺序依赖执行到一半报错时排查很费劲。.bak 还原后还要确认一件事源码里的数据库名和还原出来的库名一致不一致时改连接串比改库名省事。3.2 还原数据库与修改连接串两个最常翻车的地方用 .bak 还原时直接在 SSMS 里操作最直观也可以 PowerShell 一条命令Restore-SqlDatabase -ServerInstance .\SQLEXPRESS -Database OASystem -BackupFile D:\OA-src\Database\OA.bak -ReplaceDatabase参数说明ServerInstance 是本地 SQL Server 实例名默认实例可以写“.”或 localhost命名实例要写“计算机名\实例名”Database 是还原后的库名建议和源码 Web.config 里的 Initial Catalog 保持一致BackupFile 路径不要带中文和空格如果备份文件里记录的数据文件路径在本机不存在加上 -RelocateFile 重新指定数据文件和日志文件的位置否则还原会报“文件不能恢复”的错误。还原之后打开 Web.config重点检查连接串connectionStrings add nameOAContext connectionStringData Source.\SQLEXPRESS;Initial CatalogOASystem;User Idsa;Password你的密码;MultipleActiveResultSetsTrue providerNameSystem.Data.SqlClient / /connectionStrings这段里最容易翻车的有三处Data Source 写的是服务器名本机要改成 .\SQLEXPRESS 或 localhostUser Idsa 如果本机 SQL Server 是 Windows 身份验证模式要改成 Integrated SecurityTrue 并去掉账号密码MultipleActiveResultSetsTrue 建议保留EF6 和部分 ADO.NET 代码在同一个连接上跑多个结果集时没有这个会直接报“已有打开的与此命令关联的连接”。如果源码用的是 EF连接串可能被拆成两段一段在 connectionStrings一段在 entityFramework 节点的 defaultConnectionFactory 里。搜索代码里引用的数据库库名比一个个翻配置文件快。改完连接串重启一下网站换个 Web.config 不重启 IIS 也能自动生效但别改完就慌着检查先确认回收了应用池。3.3 端到端验证走完一次请假审批再算跑通跑通的标准不是登录进去就行而是走完一条完整审批链路。我习惯用请假审批来验证因为流程短、字段少。典型路径是登录 → 我的申请 → 发起请假 → 选“请假审批”流程 → 填表提交 → 切换审批人账号 → 我的待办 → 同意 → 发起人刷新状态确认为已通过。这一步能暴露 80% 的问题登录密码加密不对、Session 用户取不到、节点没配审批人、表单数据没写进表。发起流程的代码不管前端是 WebForms 还是 MVC最后都会归结成这个样子public ActionResult LaunchLeave(LeaveApply leave, int flowId) { var user _session.GetCurrentUser(); var instance _flowService.CreateInstance(flowId, user.UserId, Leave); _formService.SaveBusinessData(leave); _flowService.Start(instance.InstanceId, new Dictionarystring, object { [Days] leave.Days, [Amount] leave.Amount, [DeptId] user.DeptId }); return RedirectToAction(MyApply, Apply); }逻辑说明先拿当前登录用户再创建流程实例业务表保存完成后拿到主键回填 BusinessKey最后调 Start。Start 做的事是把流程实例状态改成审批中找到开始节点的后继节点根据节点的审批人配置生成待办任务。它接收的字典是给条件路由用的数据快照比如“超过 3 天要总监审批”就靠 Days 判断。参数说明flowId 是流程定义 ID在流程管理页能看到字典里的字段名必须和流程路由条件表达式里的字段名一致否则路由不生效Start 方法在不同源码里可能叫 StartProcess 或 Submit搜“CreateInstance”就能定位。跑通之后必须再做一次驳回测试审批人驳回发起人能看到意见修改后重新提交流程回到同一节点。这套能力是 OA 的底线不做等于白跑。如果流程卡住先查两张表Flow_Instance.State 和 Flow_Task.State看是实例没流转还是任务没生成。最有效的临时排查手段是在引擎入口方法加一条日志打印 instanceId、当前节点、下一个节点。改几行代码不丢人比对着黑匣子猜强。提示如果你拿到的是 MySQL 版的 ASP.NET OA连接串的 providerName 会是 MySql.Data.MySqlClient排查思路一样只是换一套配置语法。4. 把审批流改造成自己要的样子条件路由、业务表单与会签委托跑通只是开始。大多数接手源码的人真正要做的是把演示用的审批链改成自己公司的金额超过五千要经过财务和总经理三人会签三天以上请假要跳人事备案。这一章讲三件最常做的事。4.1 条件路由表达式怎么存怎么算条件路由的作用是让流程自己决定下一个节点。在数据库里它表现为 Flow_Route 表的一行从部门主管到总经理这条出线带一个 ConditionExpr 字段值可能是“Amount5000”。引擎在同意当前节点后会拿出当前节点的所有出线逐条计算条件第一条成立的路由就是下一步。商业 OA 里像泛微那种界面化配置审批流的方案本质也是这套模型只是把节点配置和条件表达式搬到了配置页面上。一个简单可靠的实现是把表达式交给 DataTable.Compute 去算前提是字段值必须做白名单校验private bool EvalCondition(string expr, Dictionarystring, object formData) { var allowed new HashSetstring { Days, Amount, DeptId, UserLevel }; foreach (var field in allowed) { if (formData.TryGetValue(field, out var value)) { expr Regex.Replace(expr, $\b{field}\b, Convert.ToString(value)); } } return (bool)new DataTable().Compute(expr, ); }逻辑说明先把表单数据里白名单字段的值替换进表达式再用 DataTable.Compute 求值。白名单是关键——如果把用户输入的字段名直接拼接进表达式等于给流程引擎开了一个任意代码执行的口子。实际操作里我还会再加一层校验表达式里除了白名单字段、数字和比较运算符其他字符一律截掉。参数说明expr 来自 Flow_Route.ConditionExpr注意数据库里怎么写代码里就必须怎么读formData 是发起流程时传进去的数据快照也就是 3.3 里那个字典。DataTable.Compute 有局限性不支持 C# 的 和 ||逻辑运算要用 AND、OR不支持中文变量名不支持带单位数值。所以设计流程时就要规定好字段名用英文布尔用 1/0日期比较先转成“yyyy-MM-dd”格式再比较。顺带说一个很多人问的需求流程表单上“根据筛选框隐藏字段”本质上跟条件路由是同一套数据。在发起页选“部门”或“金额”时前端可以根据表单快照里的字段值控制某些字段的显隐。我见过团队把这类联动逻辑放在后端生成表单 JSON结果每次改联动都要改代码发布实际上前端控制显隐就够了流程路由那边只关心真正参与判断的字段。4.2 新增一张业务表单并挂到流程上接新表单是 OA 二次开发最常做的事。步骤固定为四步建业务表、写保存方法、做发起页、配流程定义。以补卡申请为例第一步建表CREATE TABLE Leave_Apply ( Id INT IDENTITY PRIMARY KEY, UserId INT NOT NULL, StartDate DATETIME NOT NULL, EndDate DATETIME NOT NULL, Days DECIMAL(4,1), Reason NVARCHAR(500), CreateTime DATETIME DEFAULT GETDATE() );第二步在业务服务里加保存方法返回主键第三步发起页提交时先保存业务数据把返回的主键填到流程实例 BusinessKey再调 Start。后续无论在待办列表还是已办列表只要拿到流程实例的 BusinessKey 就能反查业务表把单据详情显示出来。第四步在流程设计器里复制一份“请假审批”改节点名称和审批人然后发布。表单与流程关联最容易翻车的设计把整个表单数据都存进流程表。常规做法是流程实例只存 BusinessKey 和几个参与路由判断的冗余字段明细永远在业务表里。这样审批通过后业务数据还能被其他模块继续使用。有些源码喜欢把整张表单序列化成 XML 存到 Form_Data 表改起来看着方便统计报表时要把 XML 拆开非常被动。如果你打算长期扩展建议从一开始就坚持业务表独立。4.3 会签、或签、委托的改造切入点会签的逻辑是同一个节点同时分给多个人每人产生一条待办全部同意或达到比例才进入下一节点。实现关键是在任务表加一个 BatchNo 字段同一批会签任务共享一个批次号节点完成度按批次统计var batchNo Guid.NewGuid().ToString(); foreach (var approver in node.Approvers) { db.FlowTasks.Add(new FlowTask { InstanceId instanceId, NodeId node.NodeId, Assignee approver.UserId, State 0, BatchNo batchNo }); } db.SaveChanges();逻辑说明每处理一条会签任务先查同一 BatchNo 下还有几条未办再统计已同意数量达到节点配置的阈值就把节点置为完成并继续走路由只要有一条任务被驳回根据配置可以立即驳回整个流程也可以等所有任务结束后按少数服从多数决定。参数说明节点配置表通常有 CountersignType 字段0 表示或签1 表示会签2 表示比例会签阈值存在 SignThreshold 字段比如 50 表示一半以上同意就算通过。字段名不同源码不一样但思路一致先按批次统计再决定是否流转。或签改造更简单任一人同意就把该批次其他任务全部置为“已作废”然后继续流转。委托处理的是另一个需求审批人出差时把待办交给别人。最省事的实现是在任务表加 Assignee 和 DelegatedTo 两个字段查询待办时用“Assignee当前用户 OR DelegatedTo当前用户”兜底同时保留委托记录方便追责。5. 避坑手册ASP.NET OA 源码二次开发最常见的 5 个坑下面这五个坑是我带人改 OA 源码时几乎每次都会遇到的血泪经验。每一条按现象、原因、解决来写可以直接当排查手册用。5.1 用户身份类流程发起成功却收不到待办现象用管理员账号发起流程流程状态变成审批中但审批人登录后待办列表是空的。原因绝大多数 ASP.NET OA 源码的待办查询依赖“当前用户 ID”而用户 ID 来自不同的会话来源有的模块用 Session[UserId]有的用 FormsAuthentication Ticket还有的用 HttpContext.User.Identity.Name 再去查一次用户表。流程引擎启动时把用户 ID 存错审批任务就分给了别人。解决先查 Flow_Task 表SELECT * FROM Flow_Task WHERE InstanceId 10086;看这条任务的 Assignee 值到底是谁再对比审批人用户表里的真实 UserId。定位到是哪种取值方式后把流程引擎入口改成统一从同一个 Session 变量取用户 ID。我一般会加一个 CurrentUser 过滤器强制所有模块共用一套用户上下文避免每个方法各取各的。如果是带手机端的源码类似勾股 OA 那种移动待办模式排查思路一样先看任务表的 Assignee 和移动端传上来的用户 ID 是否是同一套。5.2 流程数据类驳回修改后业务数据丢失现象审批人驳回后发起人修改单据再提交审批人看到的还是修改前的旧数据。原因表单数据在发起时被整体序列化存进了流程快照重新提交时只更新了流程状态没有更新快照里的业务数据。这是很多 OA 源码的通病快照只写一次。解决在重新提交的方法里先根据 BusinessKey 找到业务表当前数据再用它覆盖流程快照里对应字段。我习惯在表单服务里暴露一个 RefreshSnapshot 方法专门干这个public void RefreshSnapshot(int instanceId, object businessData) { var snapshot _db.FormSnapshots.First(f f.InstanceId instanceId); snapshot.XmlData Serialize(businessData); snapshot.UpdateTime DateTime.Now; _db.SaveChanges(); }逻辑说明这个方法在每次重新提交时被调用保证流程快照和业务表始终一致。注意序列化格式要和发起时一致否则读取快照的代码会解析失败。5.3 流程定义类改了流程定义老单据跟着变现象把“请假审批”从两级改成三级后正在审批中的老请假单也变成了三级审批人列表全乱。原因引擎在查询节点时按流程定义 ID 实时读取没有做版本隔离。老实例应该继续使用发起时的流程版本。解决给流程定义表和实例表各加一个版本字段ALTER TABLE Flow_Definition ADD Version INT NOT NULL DEFAULT 1; ALTER TABLE Flow_Instance ADD FlowVersion INT NOT NULL DEFAULT 1;发起流程时把当前定义 ID 和版本号一起存进实例流转时按“定义 ID 版本号”去查节点和路由而不是只按定义 ID。更稳妥的做法是发布新版本时把旧版本节点和路由复制成一套历史定义老实例走历史定义新实例走新定义。改完这步还要注意已经发起的实例 CurrentNodeId 如果指向旧节点 ID而新配置里没有这个节点流转会卡死。所以版本隔离不是加两个字段就完事流转查询要兼容历史节点 ID或在新版本发布时把在途实例统一迁移到等价的新节点上。注意版本隔离字段加完后别忘了把流程引擎里所有按 FlowId 查询的地方一起改掉漏一处等于没加。5.4 表达式与编码类条件路由不生效或直接报错现象设置了“金额大于 5000 跳总经理”的条件但五千以下也跳了过去。原因两个常见情况。一是表达式字段名和发起时传入的字典大小写不一致代码传的是 amount路由条件写的是 Amount二是路由表的 ConditionExpr 是空字符串源码把空条件当成“无条件成立”处理导致排在前面的出线总是被选中。解决在设计器里保存路由时做统一格式化字段名转小写并通过白名单校验空条件禁止保存。排查时先看 Flow_Route 表实际存了什么SELECT FromNodeId, ToNodeId, ConditionExpr FROM Flow_Route WHERE FlowId 5;再看发起流程时传的参数。多数问题一眼就能看出来。这里提醒一句条件表达式千万别允许用户在前端随意填既容易错也容易被利用常见做法是下拉选择字段和运算符由后端拼接表达式。5.5 部署类上传目录发布后打不开现象本地跑附件预览正常发布到 IIS 后同一路径返回 403 或 404。原因本地调试用的是 Visual Studio 开发服务器可写权限是当前登录用户IIS 下应用池运行身份是 IIS_IUSRS对上传目录没有写权限。另外部分源码把上传目录放在 App_Data 下IIS 默认对 App_Data 有访问保护不经过代码访问不到。解决给上传目录加上 IIS_IUSRS 写权限icacls D:\site\Upload /grant IIS_IUSRS:(OI)(CI)M参数说明(OI)(CI) 表示容器和对象都继承权限M 是修改权限覆盖读写和执行。如果附件放在 App_Data不要直接暴露物理路径改用一个 HttpHandler 读取文件流输出。大附件还要检查 IIS 的请求筛选模块限制默认约 3000 万字节超过会报 404.13需要手动调高 maxAllowedContentLength。发布时还要注意应用池的“启用 32 位应用程序”设置——有些 OA 源码带了 32 位原生组件不勾选会加载失败托管管道版本先按源码的 targetFramework 设置一般 4.0 或 4.5 都行。6. 进阶流程版本隔离和待办列表提速6.1 版本隔离给审批流定义和实例各加一个版本号流程版本隔离是审批流源码和生产环境的第一个分水岭也是审批流配置的后悔药。我推荐“定义版本号 实例版本号”双表方案流程定义表加 Version 字段流程实例表加 FlowVersion 字段发起流程时把当时的定义 ID 和版本号固化到实例里之后这个实例的每一步都在“定义 ID 版本号”下找节点和路由。发布新版流程时只改定义表旧实例不受影响新实例从新版本起跑。实现上改动很小所有查询节点的 SQL 或 EF 查询把原来按 FlowId 过滤改成按 FlowId 和 Version 两个条件过滤。代价是流程设计器保存新版本时要复制一套节点和路由但换来的是生产环境不用再挑“深夜没人审批的时候改配置”。6.2 待办提速索引与分页待办列表提速是另一个高频优化点。ASP.NET OA 源码做到后面Flow_Task 表随随便便几十万行待办查询如果写成全表 JOIN 业务表再 WHERE很快就卡死。我一般加两个索引一个在 (Assignee, State)一个在 (InstanceId, CreateTime)CREATE INDEX IX_FlowTask_Assignee_State ON Flow_Task(Assignee, State); CREATE INDEX IX_FlowTask_Instance_CreateTime ON Flow_Task(InstanceId, CreateTime);逻辑说明第一个索引服务“我的待办”列表第二个索引服务流程实例详情页和待办加速。再把待办页的默认排序改成“按创建时间倒序、只取前 50 条”搜索时可以再加时间范围条件。更深一点的做法是把待办冗余到用户维度表审批完成时用事务同步更新但这属于业务量大了以后再说的事。我自己的习惯是每改一处流程逻辑就在测试库重跑一遍“发起 → 同意 → 驳回 → 修改重提 → 同意 → 归档”这条完整链路再顺手查一次 Flow_Task 表确认没有残留待办。审批流这种东西最怕的就是改完一台机器忘了一堆任务卡在半路。这套流程成了习惯后OA 源码的二次开发就不再玄学而是有条理的活。希望今天这些经验能帮到你。本文还有配套的精品资源点击获取
RELATED

相关推荐

环形均分纸牌问题与七夕祭算法解析

环形均分纸牌问题与七夕祭算法解析

1. 七夕祭问题背景与算法竞赛视角七夕祭作为《算法竞赛进阶指南》中的经典例题,本质上是一个基于环形均分纸牌问题的变种。这个问题最早出现在日本信息学竞赛中,后来因其巧妙的数学模型和典型的算法应用场景,被广泛收录于各类算法教材。在实际…

📅 2026/10/26 17:28:47
pstack-claude:本地化大模型集成的工程范式

pstack-claude:本地化大模型集成的工程范式

1. “pstack-claude”不是工具,而是开发者社区里一个正在成型的误称现象你搜“pstack-claude”,大概率会撞上一堆零散日志、报错截图、VS Code插件配置失败记录,甚至有人把它当成某个新发布的CLI工具或IDE插件。但事实是:它根本不…

📅 2026/10/26 17:28:47
text-to-cad:自然语言驱动CAD建模的路线与实测

text-to-cad:自然语言驱动CAD建模的路线与实测

第一次在电脑前把一句“给我一个带中心孔的圆盘,外径80毫米,厚10毫米,外圈倒角2毫米”变成真正的STEP文件时,我愣了一下。这不是玩笑,也不是那种只能看不能用的“文字转3D模型”玩具,而是text-to-cad——让…

📅 2026/10/26 17:28:47
MORE NEWS

更多资讯

📰

给AI对话加跨会话记忆:从语义提取到向量召回的设计与实践

做AI辅助开发的朋友应该都有同感:同一个项目聊到第三周,新开一个会话,AI完全不记得你两周前让它梳理的那套模块边界,也不记得你已经拍板过的技术选型。你只能重新粘贴一遍背景,重新交代一遍约束,时间全耗在…

📰

智慧城市三维可视化多端协同技术解析

1. 项目背景与核心挑战 在智慧城市建设的浪潮中,"城市安全大脑"作为中枢神经系统,承担着实时监控、预警分析和应急指挥的重任。而指挥大屏则是这套系统的"眼睛"——决策者通过它直观掌握城市运行态势。但传统方案面临一个尴尬的技术…

📰

一氧化碳报警器法规解析与安装指南

1. 项目概述:一氧化碳报警器的强制安装背景 去年冬天,我邻居家发生的一起事故让我至今心有余悸。半夜两点接到电话说整栋楼在疏散,原因是某户燃气热水器泄漏导致一氧化碳浓度超标。当时消防员破门而入时,屋内两位老人已经出现中毒…

📰

claude-mem:为Claude CLI注入长期记忆的开源工具

你有没有过这种体验:用官方终端版 Claude 干活,今天聊完的项目背景、技术选型、代码规范,明天新开会话它全忘了,你又得把同样的话重复一遍。这不是你操作有问题,而是这类对话工具天然的“无状态”特性——每次会话都是…

📰

Web开发中的随机图片访问技术实现与优化

1. 项目概述"访问随机图片地址"这个看似简单的需求,实际上涉及到了网络请求、资源管理、性能优化等多个技术领域。作为一名长期从事Web开发的工程师,我发现很多初级开发者容易低估这类功能的实现复杂度。本文将从一个实际项目经验出发&#xf…

📰

agency-agents:面向复杂业务的多智能体协同决策架构

1. 项目概述:这不是一个“代理”,而是一套协同决策系统“agency-agents”这个词组乍看像拼写错误,或是某个被截断的英文短语,但放在当前技术演进语境下,它其实指向一个正在快速成型的新范式——具备自主目标感知、环境…

TODAY

今日更新

THIS WEEK

本周精选

THIS MONTH

本月热门

读完文章,想聊聊您的网站?

告诉我们您的行业与需求,资深顾问一对一梳理方案与报价,全程免费。

📞 💬