- 博客(66)
- 收藏
- 关注
RSS订阅原创 写给小朋友看的AI大模型工作原理，爸爸妈妈可以讲给孩子听
大模型其实并不会发明创造人类从未认知过的知识，例如新的数学公式和物理定律。所谓大模型的自主创作，实际上是通过概率来组合人类已有的旧知识生成新的表达。
2025-04-10 20:31:34
898
原创 DeepSeek使用技巧：R1给予灵感，V3踏实干活
R1是一个聪明、性格跳脱、天马行空的同事，总是有自己的想法，喜欢想到哪里说到哪里，常常跑题，但也经常给你提供新颖的观点，让你眼前一亮。V3是一个可靠、勤勤恳恳、认真倾听的秘书，总是忠实地按你的意图完成任务，从不逾矩。你对他做事非常放心，只是有时会嫌他死板，说什么他就只做什么。
2025-03-12 16:32:23
1411
原创 008-Trae换用DeepSeek后编程能力大幅提升至中级水平
如果说Trae+豆包0代码编程过程很折腾的话，Trae+DeepSeek则很享受。DS生成的代码完整度高、健壮性强、封装度好、可阅读性好，关键是交互焦点很清晰、不会反复犯错。可以说，Trae+DeepSeek已经具备了至少中级，甚至更高的编程水平，完全可以成为程序员的强力助手了。
2025-03-10 16:26:51
815
原创 Trae试用报告，能否真的0手写代码编写软件？
虽然最终实现了0手工代码，但实话说，所谓程序小白也能用Trae写程序是不可能的。我归纳了一系列Trae试用报告，希望对大家有所帮助。尽管问题很多，过程很折腾，但我还是鼓励大家积极拥抱AI。因为这是不可逆的大势，每个人只有跟进才不会掉队。
2025-03-08 22:00:11
815
原创 004-用DeepSeek搞定复杂的需求分析和设计
我希望DS从这些原始需求开始，分析和设计出一份逻辑完整、标准化、高规格的以微服务架构为目标的需求规格说明书出来。结果可以说是相当惊艳！它所生成的需求分析和设计相当靠谱！我仅用不到三个小时，就让DS生成了这份需求规格说明书。
2025-03-06 02:08:28
1076
原创 003-如何将DeepSeek培养成驱动企业数字化的大脑
通过将DS的推理能力与标准化的工程方法结合，向着AI驱动的企业数字化目标迈进了一大步。总结起来，以下几点是关键：知识库是核心：清晰、逻辑严谨的知识库是DS高效运行的基础。角色驱动是关键：通过定义清晰的智能体角色，可以实现多角色的高效协作。统一知识库保障逻辑一致性：所有智能体必须基于同一套知识库工作，才能确保输出的可预期性和可验证性。
2025-02-28 13:30:08
645
原创 002-AI驱动企业数字化：DeepSeek能否理解复杂庞大的企业架构？
AI在参与架构和产品设计的过程中，不断理解企业的业务、流程和规则，会变得越来越“聪明”。AI能够展开最全面的业务蓝图，深入最细致的业务关联，洞察整体业务架构却不错失任何细节。AI能够掌握企业数字化架构方法，包括从需求到集成的全过程，涉及几乎所有角色。
2025-02-27 11:39:09
838
原创 001：颠覆已至！AI将重塑企业数字化
AI正推动企业数字化从“人工铁匠铺”向“智能乐高城”转变。过去，AI被视为有限的“工具人”，仅能辅助特定任务，但随着DeepSeek等技术的发展，AI展现出惊人的思考与推理能力，成为颠覆企业数字化模式的关键力量 。
2025-02-26 07:00:00
300
原创 走出企业数字化转型困难的破局者为什么是中台架构
中台架构的出现并非人为制造而是应运而生上一篇我使劲儿吐槽了一把，把企业数字化转型困难的锅按在了IT行业背上，说IT行业落后的软件生产方式已经不适应后工业化时代、依托互联网高度协作的产业互联和企业数字化要求。IT人被我调侃成了背锅侠，腾讯阿里也调侃成了山大王。但背锅并不能掩盖我辈“挨踢”人的勤奋与创造力，今天就来点儿正能量压压惊，并为IT人正名。勇敢背锅，奋勇前行，不惧挨踢，笑看明天，才是我辈IT人应用的风骨。上一篇我说走出企业数字化困境的药方是需要把生产模式从手工作坊式变成工业化生产的专业化分工和产
2022-02-16 14:00:43
2259
1
原创 企业数字化转型困难的这个锅必须得IT行业自己来背
软件落后的生产方式才是企业数字化转型困难的病根这是老坛聊企业数字化转型和产业互联网系列的第一篇。这十几年来，我的全部精力都花在企业数字化这个大命题上了。扎扎实实的苦逼迷茫了很多年，思考问题到底出在哪儿，该怎么解决。最后我终于找到了问题的结症，也找到了治病的良方，又花了四年时间去开发治病的药。现在是时候将它们公开了。第一篇我必须得从吐槽开始，一是不吐不快，二是不知病因便无法治病。都说中国...
2019-09-03 13:41:44
1505
6
原创 【有明信息】虚实之间 ---关于企业架构是与非的探讨
管理理论自然为“虚”，将管理理论渗透到日常生活工作中，正视问题，运用管理方法，执行它，才能“实”。
2014-09-23 11:51:42
6578
3
原创 [有明信息]重视测算，精校成本源头 ——浅谈房地产开发目标成本测算
目前，业内基本是以目标成本作为成本管理的原点，其作为后续成本控制的基线，同时也将在责任成本管理、前期设计优化、招投标管理等环节发挥有效的指导作用。可以说目标不准确，过程管控再严格，也将枉然。
2014-08-25 15:38:09
7146
原创 [有明信息]房地产开发，如何让营销后队变前队----契合项目开发全周期，实现营销全过程管控
如何让产品设计以客户为中心，充分尊重客户需求与体验，建造针对性更强的产品？如何动态掌控供应量，精准制定推盘策略？地产企业已经面临现实的问题和挑战。在当前形势下，地产企业唯有变革创新。其中，让营销真正由“后对”变“前队”，是重要的一步。具体来说，我们认为应该契合项目开发全周期，实现营销全过程管控，自始至终做好项目开发价值链各个环节的工作，让营销活动贯穿项目开发始终，做到“营销全周期管理”。那如何改变？
2014-08-14 18:21:42
6960
1
原创 [有明信息]横向集成、纵向贯通 ——地产财务管理新思路
“横向集成，纵向贯通”的理念在世茂集团及有明信息同事的共同努力下已初见成效。“一体化运营”的管理思路及财务业务一体化管理平台无疑是地产行业从“粗放式”管理向“精细化”管理战略转型的最佳途径，也是“深陷泥潭”的财务管理从核算型向管理转型的基础。在财务业务一体化管理平台当中，体现了集团、区域（城市公司）、项目公司的纵向一体化管理，也体现了营销、财务、工程、成本、合约的横向一体化集成。
2014-08-08 11:22:53
8890
原创 [有明信息]科目导向，精耕细作 ——浅谈房地产开发成本管理
题记：2014年7月3日，世茂集团宣布，作为中国地产行业首家采用SAP ERP一体化信息平台的企业，世茂集团ERP系统已成功上线并取得卓越成效：自2013年全面运行以来，世茂集团成功采用这一“横向集成、纵向贯通”的信息化平台，实现了业务财务一体化、以及覆盖项目开发全生命周期的协同管理，并打造了全面的战略经营管控模式。原文链接：http://mp.weixin.qq.com/s?__bi
2014-08-06 11:40:58
6682
原创 《大象--Thinking in UML 第二版》已于近日在当当首发，同时邀请各位加入新浪微博[大象-thinkinginUml群]：http://q.weibo.com/1483929
《大象--Thinking in UML 第二版》已于近日在当当首发，感兴趣的朋友可以去看看http://product.dangdang.com/product.aspx?product_id=22625408 。先附上再版自序吧。同时邀请各位加入新浪微博[大象-thinkinginUml群]：http://q.weibo.com/1483929 再版序《大象—Think
2012-03-19 16:17:37
14646
32
原创 BPM 是与非 -- 什么是BPM，如何辨别是否BPM产品，以及如何选择BPM产品
BPM方兴未艾，然而眼见市场上BPM产品一片混乱，你方唱罢我上场，各色产品、各种概念粉墨登场。虽然百花齐放，但真正有志于实施BPM的客户却被这乱花迷了眼，实在搞不清楚BPM该怎么去做，最终失去对BPM的信心和关注。这于BPM的发展并无益处。由是撰写此文，从BPM的基本概念出发，讲解了一些如何辨别和选择BPM产品的建议。希望能为BPM市场的进一步发展带来一点帮助。什么是BPMBPM（Busi
2012-01-11 14:39:43
10397
原创 关于采用业务用例视图来展示、归纳、整理业务用例的三点指导原则
今日，网友LeoXu给我发了封邮件，提到了业务建模如何组织业务用例的问题。这个问题还是第一次被问到，而且Leo同学显然走了一点小弯路。在回答他的同时，他的这个问题也非常好，把它分享出来。另一方面，Leo同学显然是喜欢思考的，他给我问题的同时也包含了他的许多思考，这点要赞之。为了表示对他热爱思考的鼓励和赞许，特地在最后又留了一个问题，请Leo同学来回答。同时也欢迎各位网友就该问题畅所欲言！Leo同学
2011-11-08 14:18:20
9963
原创 OO系统设计师之路--设计模型系列(1)--软件架构和软件框架[从老博客搬家至此]
软件架构是一种思想，一个系统蓝图，对软件结构组成的规划和职责设定。而软件框架是一个实现，一个半成品，是针对一个特定问题的解决方案和辅助工具。
2010-10-18 16:00:00
11834
6
原创 OO系统设计师之路--分析模型系列(3)--分析模型的调整和优化[从老博客搬家至此]
草图代表了需求的实现，是一个细节的表露。接下来的优化的调整，就以此为基础。主要的输入：草图，系统架构，业务规则，补充用例规约，系统原型。主要的输出：调整后的分析模型，子系统，组件视图和部署视图（针对分布式应用而言）
2010-10-18 15:58:00
9119
1
原创 OO系统设计师之路--分析模型系列(2)--怎样做分析模型 [从老博客搬家至此]
分析模型是系统的高层抽象，是高于实现语言和实现方式的。因此在做分析模型过程中，要跳出固有的java思维，C++思维，同时也暂时不要考虑设计模式的应用，而专心的，用OO思维把四个分析类的职责和交互，以及它们之间的关系定义清楚。如果说用例分析大部分情况下是程式化的（笔者正希望它是程式化的），那么你会发现，分析模型大部分工作也是程式化的。
2010-10-18 15:54:00
9097
1
原创 OO系统设计师之路--分析模型系列（1）--什么是分析模型 [从老博客搬家至此]
分析模型是高层次的系统视图，在语义上，分析类不代表最终的实现。它是计算机系统元素的高层抽象。笔者认为分析模型正是OO设计的核心，而设计类只是OO的实现手段。分析模型是MVC模式的经典应用。对比分析类的名称，MVC模式，读者应该能够发现分析类在OO和商业目标中精妙的对应关系：人，事，物，规则--actor,boundary,engity,control。这就是为什么笔者说分析模型是OO设计的核心。
2010-10-18 15:43:00
11150
1
原创 面向对象方法中的数据库设计
最近收到不少网友关于在面向对象的分析设计中如何进行数据库设计的疑问。在大象-thinking in uml一书里，我详细讲述了面向对象从需求到设计的整个过程，但确实对数据库设计着墨甚少。因此写这篇文章对这个问题详细说明，在第二版里应当也会加上这一部分。 先贴出一位网友的疑问以及我的回复，作为这篇文章的引子：网友fdshxp问道：在软件开发时要进行数据库设计，现在通常的做
2010-02-05 15:21:00
23923
33
原创 业务用例向系统用例转换方法的一个讨论
最近收到一封网友来信，询问关于业务用例向系统用例转换的问题。觉得这个问题比较有意义，涉及到了业务用例向系统用例转换的策略以及评判方法，特发表上来，并感谢rainyhuang网友： rainyhuang的来信： Dear CoffeeWood, 你好,看过你的文章使我对OOA有了更深的了解,但我在实际工作过程中遇到了一个问题让我百思不得其解,请不吝赐教,谢谢.
2009-12-22 14:28:00
9313
4
原创 蜂巢 - Thinking in Agile - 我们需要怎样的软件过程(2)
第一篇文章以蜂群作为引子，讲述了作为一个优秀的敏捷团队，蜜蜂们是如何工作的。得到了众多网友热情的回复，首先在此做谢！ 方法是靠不住的，人性才是永恒的 到现在为止，所有的回复中还没有人反对蜂群是最优秀的敏捷团队这一观点。似乎我们可以简单的这样认为：所有人都认同蜂群是最优秀的敏捷团队，如果我们要组建一个敏捷的团队，我们就有必要从蜂群那里学习点什么。毕竟
2009-07-28 01:43:00
9033
16
原创 蜂巢 - Thinking in Agile - 我们需要怎样的软件过程(1)
前言 Thinking in UML 系列文章是从2005年开始写的，至2008年终成《大象-Thinkin in UML》一书，江郎才尽矣，UML系列文章也该停下来了。一方面固然是因为《大象-Thinkin in UML》一书已经掏空了我关于UML和OO分析设计方面的积累，实在已经没有什么新鲜玩意儿值得一说了；另一方面，2005到2009已经发生了很多变化，我的关注点也有所转移，这次是敏捷
2009-07-19 22:50:00
9989
24
原创 开发即过程！立此纪念一个IT新名词的诞生
近日拙文“Jazz--开放协作与开发即过程的前奏”参与了 Rational技术征文大赛 见http://tech.it168.com/focus/200903/rationalgame/index.html， 很荣幸获得了头名， 见http://www.itpub.net/viewthread.php?tid=1176225&page=1&extra=page=1不过对我个人来说最
2009-06-18 10:47:00
8971
14
原创 邀请大象一书的读者和广大网友写关于分析设计、建模方面的自愿者文章
一直以来都是我写给大家看。与Arthur网友的互动让我觉得，其实网友自己的心得体会也是非常有价值的，可能更符合学习者的心路历程。在我的博客里已经发表了Arthur网友关于“业务场景和业务用例场景的区别”的文章，写得非常好，这更加引起了我的兴趣，相信广大网友中藏龙卧虎者大有人在，如能将这些资源都发掘出来，对大家的帮助就更大了。 由于我的博客专注于系统分析设计和建模，有一定的知名度，将文章集中
2009-06-01 16:22:00
7180
9
原创 业务场景和业务用例场景的区别(作者：Arthur网友)
简单点说，在以业务目标为边界的业务模型中，业务场景图描绘的是贡献于这个业务目标的什么人及其做的什么事，这些人和事的交互过程和完成顺序就是完成整个业务目标的流程。而这些人往往是业务主角、而他们所做的事便是业务用例了。所以我认为，绘制业务用例图和业务场景图并没有谁先谁后的问题，这两个图是互相验证的。可以先绘制业务场景图，然后把其中的泳道和活动拿出来，得到的就是活生生的业务用例。但根据业务场景图得到
2009-06-01 16:08:00
26980
9
原创 OO系统分析员之路--用例分析系列（8）--如何编写一份完整的UML需求规格说明书[整理重发]
终于到了快结束的时候了，这将是用例分析系列的最后一篇，结果是得到需求规格说明书，以结束需求分析的过程。经过前面七篇的工作，我们从最初的业务用例获取入手，获得了业务用例模型，这是我们的业务范围；经过分析得到了业务场景，这是我们的业务蓝图；经过规划，得出用例实现视图，这是我们的系统范围；经过再次分析，得到了用例实现以及领域模型，包括用例规约，业务规则和业务数据，这是我们的概念模型。仅从需求所需的必要
2009-05-14 15:53:00
9750
6
原创 最近评论回复汇总
Re: 《大�?Thinking in UML》读者专用反馈、答疑、讨论贴cej19820202 | 5/16/2009 10:19:44 PM | 删除回复 | 选择大哥 我的光盘丢了 怎么�?d=0.21383061977772044re:cej198202025/19/2009 12:25:32 PM | 删除有网友在CSDN上传了随书光盘的下载，你去下一个吧R
2009-05-14 15:46:00
3159
6
原创 OO系统分析员之路--用例分析系列（7）--用例规约的编写--业务规则和实体描述[整理重发]
先说说业务规则。笔者习惯将业务规则分为三种。一种是全局规则，这种规则一般与所有用例都相关而不是与特定用例相关，例如actor要操作用例必须获得相应的授权，用例的操作与授权级别相关，或者用户在系统中的所有操作都要被记录下来等等。这类规则笔者习惯于，并且也建议将它们写到用例的补充规约里面去，因为它们一般与具体的业务功能性要求没有直接关系。有时候，这类规则也被写到软件架构文档中。关于用例补充规约
2009-04-14 17:29:00
17009
12
原创 回复网友 man1231，关于业务目标界定的问题
man1231 咖啡，你好： 有2个问题请问： 1. 根据业务目标来确定边界，从而产生主角和业务用例。 请问，“业务目标”如何产生 ？ 根据用户的描述或者根据标书的要求来就可以了吗？ 在多个“业务目标”之间，有无层次关系？ 能否对“业务目标”的梳理，有个更明确的做法？ “业务目标”
2009-03-06 17:23:00
3455
原创 回复网友xiaobai1023的用例分析问题
网友xiaobai1023： 谭老师，你好：我有这样一个需求：通过调度框架如（quartz）定时去执行一些动作，动作的内容是去取一些“原始数据”可能是一些文件，也有可能是通过socket向第三方系统发送一条命令得到的数据，将得到的这些原始数据通过一些数据的映射、转换组装成我的上层系统中的值对象上传。可能是需求简单的缘故，本身实践UML的时间也不长，产生了如下疑问，希望您能帮助解答一下，谢谢
2009-03-04 14:44:00
3028
9
原创 OO系统分析员之路--用例分析系列（6）--用例实现、用例场景和领域模型[整理重发]
上一篇说到我们经过初步的业务分析，得到了用户、业务用例以及业务场景模型。这三项工作成果形成了基本的需求框架，并圈定了业务范围。这时应当做一份基线。当然，第一份基线所包括的内容是非常粗的，要达到完整的需求说明还有更多工作要做。这一篇就来说说详细的需求过程和产出物，以及这些成果对需求的贡献。在开始之前，还是提醒读者下载实例，本文下面只会从实例中挑选很少一部分来说明，对照实例读者将能更好的理解。
2009-02-09 21:41:00
9196
11
原创 《大象》勘误专用帖
1.网友newsunet的指正： P70：图3.21展示了实体发现的结果。翻阅前面的图，发现应该是图3.17。图3.21是一个预存话费的例子。 2. 网友 mrwang指正：P92的“概念用例视图”第一段：概念用例和业务用例之间的关系，一般来说这些关系有扩展，包含和精化。P122“概念用例模型”第四段最后一行：抽象出的概念用例通过包含，泛化，扩展关系连接到基
2009-01-12 14:59:00
6634
67
原创 用例规约要细致到万无一失吗？
网友的来信： 谭先生，您好！ 最近在拜读您的大作《大象》，收益良多，正是我在寻找的一份有正在将uml运用于实际场景过程的好教材。在阅读中，我反复回顾并结合了我在实践中的一些积累。有一个关于用例规约的小问题想请教下。 先介绍下问题的背景，我从事的产品以web界面为主，业务逻辑本身并不十分复杂，产品设计人员产出物为 用例规约和原型demo，开发即开始进行相应的表设计，开发，没有做到
2009-01-12 14:36:00
6695
9
原创 关于业务用例抽象问题对网友的回复
谭老师，您好我现在有一个疑问，在银行的自助终端系统进行业务建模时，客户端（即自助终端）连接银行中间业务平台系统。终端用户可以利用自助终端进行如下操作，如终端用户业务用例图所示自助终端的业务用例图如下图所示：问题1) 我把所有终端用户的请求在自助终端用例图里都概括转化为一个“业务请求”，您觉得这么做合适吗？应该怎么做呢？下面是订购机票的业务场景图，如下图所示问题2) 在这里
2008-12-31 13:59:00
3875
7
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人