- 博客(52)
- 资源 (5)
- 收藏
- 关注
RSS订阅
原创 5款好用的项目管理软件推荐
1.JARAJIRA是集项目计划、任务分配、需求管理、缺陷跟踪于一体的软件。它基于Java架构的管理系统，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。2.CORNERSTONECORNERSTONE是一款易用强大的项目管理工具，体验比较棒，集项目管理、Devops、知识库管理、文件管理于一体。3.禅道禅道时间比较久，...
2019-08-14 18:45:07
5375
原创 一个库存数字从仓库、库位、物料、单位换算走到即时库存，准确性就藏在这些基础动作里
库存系统里最常被问的一句话是：这个产品还有多少？看起来，系统只需要给出一个数字。真正落到企业现场，这个数字必须同时回答：它在哪个仓库、哪个库位，属于哪个店铺和产品，用什么单位记录，一箱与一件如何换算，当前数量又是由哪些业务动作累积出来的。仓库、库位、物料或单位任何一层没有定义清楚，最后的库存数字再精确，也可能无法被采购、仓库、运营和财务共同使用。所以，库存可信不是从库存余额表开始的。它首先是一条主
2026-10-24 16:21:46
334
原创 一款服装从选品共享、尺码、起订量走到确认采买，采购决策的价值就藏在这些连续动作里
服装采购前，候选款常因信息碎片化导致决策混乱。织信通过“选品共享”与“采买信息”双入口，将款式从群聊流转转为可追溯的业务记录：候选款统一归集，状态清晰标注；关键条件如尺码、起订量、面料、价格等逐项确认，避免反复返工；采买状态明确区分“待确认”与“已确认”，确保采购有据可依。系统以结构化数据串联选款、核对、决策与执行，实现从看款到下单的连续闭环，提升协同效率与准确性。
2026-10-13 16:47:22
7
原创 一家供应商从临时合作、准入审核、能力评审走到正式入库，供应商管理的价值就藏在这些连续动作里
供应商不是填完名称、联系人和电话，就可以直接进入采购系统。一家新供应商从被业务人员找到，到真正承接企业订单，中间还要经历资料登记、类型判定、准入审核、能力评审、分级定责和正式入库。如果这些动作只发生在聊天记录、邮件和多份 Excel 里，采购看到的只是一个供应商名称，却很难确定它为什么通过、适合做什么、当前能否继续合作。所以，供应商管理不是通讯录。它是一条从候选资源到合格交付能力的转换链路。企业在
2026-10-08 12:24:12
166
原创 一个跨境 SKU 从建档、采购计划、发货计划走到装箱，货件管理的价值就藏在这些连续动作里
跨境电商里，一个 SKU 看起来只是一串编码。它进入实际履约后，却要同时连接店铺、产品档案、采购计划、供应商、发货方式、货件编号和装箱结果。只要其中一段断开，业务就会回到手工核对：运营不确定该补哪个商品，采购不确定用哪份产品资料，物流不确定哪些货应该装进同一个箱子。所以，货件管理不是建一张发货表。它要让同一个 SKU 从运营侧一直走到实物出库，且每一步都能回到同一份业务身份。跨境商品的编码并不只有
2026-10-05 10:43:08
197
原创 一个采购订单从录入、校验、审批、通知走到执行，企业自动化的价值就藏在这些连续动作里
采购订单进入系统之后，真正重要的并不是多了一行数据。它要同时回答很多问题：供应商是否有效，物料与价格是否匹配，金额是否超出权限，交期能否满足生产计划，审批通过后由谁执行，异常发生时又该通知谁。这些动作如果散落在表格、聊天记录和人的记忆里，订单看起来已经录入，业务却仍然没有真正进入系统。企业级采购表单不只是填写供应商、物料和数量。它还需要关联采购计划、产品资料、历史价格、合同条款和交付要求。当订单字
2026-10-05 10:36:49
205
原创 一款服装从开发、配色、采购、供应商协同走到交付，服装外贸数字化的价值就藏在这些连续动作里
服装外贸的订单，表面上是一张款号、数量、价格和交期组成的表。真正进入执行以后，一张订单会迅速展开成几十个互相依赖的动作：款式立项、颜色确认、面料选择、尺码配置、采购下单、供应商确认、面料到仓、开裁、上线、后整、验货和发货。其中任何一个节点发生变化，都可能影响成本、品质和最终交期。所以，服装外贸数字化不能只做订单登记。系统要管理的是一款服装从产品定义到生产交付的完整链路。服装业务的起点不是采购订单，
2026-09-30 13:05:36
207
原创 一个工程项目从计划、合同、变更、验收、付款走到结算，项目管理的价值就藏在这些连续动作里
工程项目启动以后，现场每天都在发生变化。总体计划被拆成专项计划，合同陆续签订，施工过程中产生签证变更，完成的工序等待验收，合同根据进度付款，最后再按实际工程量办理结算。这些动作分别由项目、工程、成本、合同、财务和监理等不同岗位完成，但它们不能各自停留在一张表里。计划延期会影响资源和付款安排，变更签证会改变动态成本，验收结果会影响产值确认，已付款金额又必须回到合同执行和最终结算中。真正的企业级项目管
2026-09-27 22:56:31
210
原创 一台设备从建档、点检、报修、维修走到恢复生产，EMS 的价值就藏在这些连续动作里
制造企业的设备管理，往往从一张设备台账开始。设备编号、设备名称、型号规格、所属部门、启用日期、生产厂商，这些字段当然重要。但一台设备真正进入生产现场以后，问题就不再只是“这是哪台设备”。它每天有没有按要求点检？哪些异常在点检阶段就应该被发现？
2026-09-27 10:31:34
237
原创 一名员工从招聘、入职、试用、合同、考勤走到转岗离职，OA 的价值就藏在这些连续动作里
制造企业招进一名员工，表面上只是花名册里多了一行。真正发生的事情却远不止这些。用人部门提出招聘需求，人事收集简历、安排面试、确认录用。员工报到以后，要建立档案、签订合同、进入试用期。部门负责人要完成试用评价和转正审批，日常工作中还会发生考勤、请假、调岗、奖惩、续签和离职。每一个动作都会改变员工状态，也会影响组织关系、审批路径、系统权限、生产排班和管理统计。如果 OA 只做成通讯录，这些动作仍然要靠
2026-09-21 21:11:25
210
原创 一个新品项目从客户需求、BOM、问题、成员协同走到量产准备，APQP 的价值就藏在这些连续动作里
制造企业接到一个新品项目以后，真正的挑战不是把项目名称登记下来。项目会从客户需求开始。会进入图纸和技术评审。会拆 BOM。会报价。
2026-09-20 17:14:04
182
原创 一个采购订单从确认、发货、到货走到入库，SRM 的价值就藏在这些协同动作里
理解企业级落地时，关键往往不是系统名称本身。关键在于读者能看到一张生产订单怎么从计划、领料、报工、质检走到出货。业务是连续的。系统也必须连续。
2026-09-16 12:44:24
151
原创 一个质量问题从送检、检测、判定走到闭环，QMS 的价值就藏在这些连续动作里
企业级落地写到 MES 时，读者更关心的不是系统名称，而是一张生产订单到底怎么在现场流动。同样，写到 QMS，也不能只说“质量管理系统”。真正到现场时，质量问题从来不是一张孤立的质检表。它会从生产现场出现。
2026-09-15 10:45:07
171
原创 企业级落地 ：一个生产订单，在 MES 里怎么从计划走到出货
企业级落地不能一直停留在平台能力层面。真正到现场时，问题会变得非常具体：一个生产订单进来以后，怎么从计划、领料、生产、报工、质检，一直走到出货。制造企业里，很多生产问题不是没有系统，而是链路断在中间。销售接到订单以后，生产计划在 Excel 里排。
2026-09-09 10:18:03
226
原创 企业级落地 ：织信如何成为企业级信息化系统的底座
本文记录织信企业级信息化系统底座的落地思路：企业系统不是孤立交付，而是在同一平台上围绕数据模型、流程、权限、运行端、自动化、集成和 AI Agent 持续生长。
2026-09-06 17:25:35
202
原创 织信开发日志 26：AI 为什么会胡说？因为它拿错了资料
本文记录织信知识库在企业 AI 场景里的边界：知识库不是把资料堆给 AI，而是让 AI 在正确角色、正确权限、正确资料范围内回答，并能被约束、验证和追溯。
2026-09-04 09:05:11
328
原创 织信开发日志 25：技能不是插件市场，而是 AI 的手
本文记录织信里创建真实技能的过程：技能不是给 AI 多装一个插件，而是把平台业务能力变成 AI Agent 可以调用、可以限制、可以审计的动作。
2026-09-03 11:20:44
195
原创 织信开发日志 24：智能助手，不能只是回答“怎么操作”
本文记录织信智能助手在客户跟进应用里的真实使用过程：智能助手不应只是回答怎么操作，而要进入业务现场，读取应用数据，形成优先级判断，并给出下一步动作。
2026-09-02 21:05:27
218
原创 织信开发日志 23：AI 网站，不是生成一个漂亮首页
本文记录织信 AI 网站模块的真实创建链路：网站不是孤立展示页，而是应用里的业务入口。AI 需要在应用上下文中创建模块、生成页面，并继续把提交动作接入数据表和平台 API。
2026-09-02 07:48:57
342
原创 织信开发日志 22：智能体对话开发，不是接一个聊天框
本文记录织信智能体对话开发的真实链路：入口不在孤立聊天框，而在创建应用流程里。AI 读取 Skill、创建应用骨架、串行建表、发布并插入测试数据，最终生成可运行的业务应用。
2026-08-30 22:57:53
351
原创 织信开发日志 21：别让 AI 变成团队里的超级管理员
本文继续拆 Team Skill：AI Agent 进入企业系统后，不能绕过人的权限体系。团队、成员、角色和高影响操作必须成为 Agent 行动前的边界。
2026-08-28 13:48:08
337
原创 织信开发日志 20：AI 建应用之前，必须先知道自己在哪
当团队、应用、分组、模板这些入口上下文都确认以后，AI 才应该进入设计器。这时候它再去建表、加字段、生成页面，动作才有依据。它知道应用属于哪个团队。知道是不是新建应用。知道是否已有相似应用。知道当前用户是否有权限继续配置。知道后续操作影响的是草稿结构，还是已经发布过的应用。这一步之后，Designer Skill 才真正接上。比如查询对象。创建表。增加字段。生成页面。配置视图。接入自动化。如果跳过 Workbench，直接进入 Designer，AI 也许能做出一套完整结构。
2026-08-27 16:32:18
305
原创 织信开发日志 19：为什么 Skill 不能只是工具列表
本文从 informat-skills 继续拆 Skill 的设计：工具列表只是第一层，真正让 AI Agent 可靠操作平台的是调用规则，包括参数来源、执行顺序、环境边界、危险动作确认和失败处理。
2026-08-25 14:21:09
300
原创 织信开发日志 18：从 informat-skills 看织信如何把平台能力交给 AI Agent
本文从 informat-skills 这套 Skill 出发，拆解织信如何把 Workbench、Team、Designer、User 和 Common 等平台能力整理成 AI Agent 可以理解、调用并受控执行的能力层。
2026-08-24 22:57:31
215
原创 织信开发日志 17：织信 Skill 的目的，是把平台能力交给 AI Agent
织信 Skill 的核心价值，不是让 AI 说得更像产品经理，也不是让 AI 写出更漂亮的需求文档。它的价值是把织信的平台能力变成 AI Agent 可调用的工具集。
2026-08-23 08:15:00
738
原创 织信开发日志 16：AI 生成应用，最危险的是看起来已经完成了
AI生成应用最大的风险在于"虚假完成感"。系统能快速生成完整页面和字段，但真正的业务问题藏在字段语义、权限控制、异常处理等细节中。空系统无法暴露这些问题，必须用接近真实的数据进行验证，才能发现字段类型、关联关系、权限控制等方面的缺陷。AI低代码的真正价值不是快速搭建原型，而是提前暴露未完成的部分。开发者需警惕表面完整性，通过真实业务数据测试来戳破"已完成"的幻觉。
2026-08-22 10:15:00
318
原创 织信开发日志 15：AI 生成数据表，真正困难的不是识别字段
【摘要】AI生成数据表的真正挑战不在于字段识别，而在于业务语义转化。本文指出关键难点包括：1）字段类型需匹配业务逻辑（如用户选择而非纯文本）；2）派生字段需识别计算规则；3）关联关系需确保数据联动；4）需设置数据校验规则。理想流程是AI先识别业务对象，选择语义化字段类型，建立正确关联，设置验证规则，最后通过测试数据闭环验证。评估标准应关注业务语义准确性、数据类型适配性、关系完整性、数据质量保障和关键决策的人机协同，而非单纯字段数量。
2026-08-21 00:21:57
343
原创 织信开发日志 14：表单引擎不是页面生成器，而是业务入口
本文探讨了低代码平台中表单引擎的核心价值：表单不仅是数据录入界面，更是业务系统的关键入口。文章指出，优秀表单设计需考虑：1)基于数据模型构建字段结构；2)合理设置必填规则避免数据污染；3)字段类型决定后续业务能力；4)支持多角色差异化呈现；5)与业务流程和自动化紧密联动；6)需具备AI可理解的语义化特征。表单引擎的深度决定了企业数字化系统的扩展性和智能化潜力，其本质是承载业务规则的数据交互枢纽而非简单的页面生成器。
2026-08-20 09:45:00
442
原创 织信开发日志 13：从项目管理系统看低代码里的数据模型设计
【摘要】本文探讨低代码平台中项目管理系统数据模型的设计要点。AI生成的5张核心表（项目、任务、里程碑、工时、风险）展示了合理的业务对象拆分逻辑：以项目为主对象，关联多个明细表实现一对多关系。数据模型设计需明确主对象字段的业务用途，如项目编号用于识别、状态用于流转。独立成表原则确保任务、工时等明细数据的结构化存储，为统计分析和自动化提供基础。关系字段的准确定义是系统扩展性的关键，使AI能理解业务逻辑实现智能统计。作者指出，低代码平台的核心价值不在于表单设计，而在于通过合理的数据模型支撑完整的业务流程。
2026-08-19 22:50:46
164
原创 织信开发日志 12：AI 生成应用后，哪些地方必须人工校准
本文总结了AI生成应用后需要人工校准的六个关键环节：1. 字段校准（业务规则验证）2. 必填项校准（避免无效强制）3. 选项值校准（匹配实际业务流程）4. 页面入口校准（角色化导航设计）5. 测试数据补充（验证业务路径）6. 权限与自动化校准（细粒度控制）。作者提出"AI执行+人工判断"的协作模式，强调AI更适合完成0到1的框架搭建，而1到100的精细化调整仍需结合业务判断，建议按照数据模型→字段规则→页面设计→测试验证→权限控制的顺序进行系统校准。
2026-08-18 19:24:57
198
原创 织信开发日志 11：AI 智能体如何从一句话生成应用
本文记录了织信AI智能体从自然语言需求到生成可运行应用的全过程。作者通过创建"项目管理系统"案例，重点验证了AI将一句话需求转化为应用落地的能力：1）智能体需将自然语言拆解为数据结构（表、字段、关联关系）和页面入口；2）成功生成5张关联数据表并发布运行态应用；3）强调AI的目标不是完美系统，而是生成可修改的基础框架，帮助用户跨越初始设计门槛。实验证明AI能有效完成需求翻译和应用初始化，但复杂功能仍需人工校准，体现人机协作的实施价值。
2026-08-15 09:49:32
181
原创 织信开发日志 10：AI Agent Skill 不是提示词，而是平台操作协议
本文探讨AI与低代码平台深度整合的关键机制。作者指出AI不应仅作为聊天入口，而需具备操作系统的协议化能力。通过"Skill"设计，平台将功能拆解为可验证的原子操作：要求AI必须遵循"先查询再修改"原则，通过分层权限控制（团队角色/会话模式/业务权限/安全策略四层）确保操作安全，尤其对设计端变更采取小步执行策略。这种结构化方法使AI既能自动化流程（如创建应用需分步完成数据表构建、字段补充等），又能保持操作可追溯、可中断，最终实现AI在权限边界内代替用户安全操作系统，而非
2026-08-13 13:19:24
359
原创 织信开发日志 09：低代码平台里的脚本应该怎么设计
本文探讨低代码平台中脚本功能的设计思路。作者指出脚本是处理复杂业务逻辑的必要补充，但需注意边界控制：脚本应专注于特定计算任务，而非替代整个业务流程。平台需提供托管机制，将脚本作为"计算节点"嵌入自动化流程，同时严格管理其访问权限和运行环境。关键设计原则包括：通过平台对象暴露能力、保持业务链路可视化、实现脚本全生命周期管理。最终目标是既保留处理复杂逻辑的灵活性，又不破坏低代码平台的可维护性和可追踪性。
2026-08-12 15:23:42
338
原创 织信开发日志 08：自动化不是定时任务，而是业务动作的编排
本文阐述了织信系统中自动化的核心定位——业务动作编排层，而非简单的定时任务。作者指出，企业级自动化需要具备接收参数、变量处理、条件判断、循环执行等能力，形成可复用的业务逻辑单元。通过图形化界面，自动化能串联数据操作、API调用、脚本执行等步骤，并支持参数输入和结果返回，使其成为可组合的业务函数。文章强调自动化应作为业务动作的统一抽象层，既便于实施人员理解，又方便开发维护，同时需设置执行边界保障系统稳定性。最终指出自动化与表单、流程、脚本等组件协同，构成完整的低代码业务解决方案。
2026-08-11 11:23:20
386
原创 织信开发日志 07：低代码平台为什么一定要有插件机制
【摘要】本文探讨低代码平台插件机制的设计理念，提出应以"入口分散、逻辑集中"为原则。织信的插件机制并非独立代码块，而是由监听器（事件入口）、API（外部系统入口）、自定义控件（界面入口）三类扩展点构成，通过自动化（编排层）和脚本（复杂逻辑层）集中处理业务逻辑。这种架构需配套权限管控、执行日志等治理能力，避免系统失控。核心思想是：扩展入口要丰富，但业务逻辑应收敛至统一处理层，在灵活性与可维护性间取得平衡。
2026-08-10 09:15:51
351
原创 织信开发日志 06：流程引擎不只是画审批流
本文探讨了低代码平台中流程引擎的深层价值，指出其远超出简单的审批流绘制。作者提出流程本质是业务状态机，应以数据状态变化为核心，而非图形界面。关键观点包括：流程必须绑定具体业务对象以读取字段数据；审批人需支持动态配置；条件分支应具备透明可解释性；退回机制需灵活设计；流程状态变化应联动权限体系；需支持自动节点实现业务编排；完整的流程记录比流程图更重要。文章强调流程引擎是企业业务运行的协调中枢，需与数据模型、权限体系深度整合，才能真正支撑复杂业务场景。
2026-08-09 22:00:32
320
原创 织信开发日志 05：低代码平台的权限体系为什么这么难做
本文探讨了低代码平台权限体系设计的复杂性。作者指出，权限不仅涉及菜单访问，更关键的是动态数据权限、字段权限和流程权限的精细控制。在低代码环境中，由于业务对象、组织结构和流程节点都是动态变化的，权限系统需要支持多维度控制（角色、组织、数据归属、流程节点等），并处理行权限与字段权限的相互影响。特别强调了流程中的动态权限变化、AI时代权限安全的重要性，以及避免常见的权限设计误区（如过度依赖角色、后补字段权限等）。理想的权限体系应平衡灵活性与安全性，既满足常见场景的简单配置，又为复杂需求提供解决方案。
2026-08-08 17:03:42
316
原创 织信开发日志 04：低代码平台的数据模型应该怎么设计
本文探讨了低代码平台数据模型设计的核心问题。作者指出，数据模型不应简单理解为建表加字段，而需构建包含元数据和业务数据的两层结构。关键设计原则包括：以业务对象而非页面为中心构建模型；注重字段的业务语义表达；正确处理对象间关联关系；在动态配置与系统稳定性间取得平衡。同时强调数据模型需为权限控制、流程引擎、报表分析和AI应用提供底层支撑。文章最后总结了常见的设计误区，提出低代码平台的核心价值在于将企业业务抽象为可演进的数据模型，这比功能数量更能决定平台的长期发展潜力。
2026-08-06 21:19:38
313
Android apktool
2015-05-21
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人